Hi Tom,On 11 Oct 2009, at 16:33, Tom Taylor wrote:
I am looking for some principles here, so I've been dithering a bit myself over
the appropriate use of the Generic Response message.
I see. It seems fairly evident to
me that Generic Response should be used to convey error status that is common to
multiple message types, justifying the definition of the error cases in base
rather than another document.
The simple case is for "unrecognized/invalid message" where we need a generic message.
And I believe strongly that if there is
information that should be sent in a response in answer to a particular message
type, and that information is specific to that message type, then the response
message should be of the same type as the original request.
The questions in my mind begin when you have the latter case, but you have a
generic type of error to report.
Agreed. Do you report the error in a Generic Response,
or in the defined response message using a Status TLV embedded in that response
message? I think you do, to simplify the message-processing state machine. And
that means some changes in some of the work we have done already. Particularly,
my colleague Fortune Huang (18/08/2009) pointed out the complexity of handling
Delegated Bandwidth Query
That's probably a good case to look at.
There are some errors that are fairly specific to the Delegated Bandwidth Query (for example"Bandwidth Delegation not activated"). I understand you're saying you'd like to see those conveyed inside the "Delegated Bandwidth Query Response".
There are also some errors that are independent of the actual query type (for example "invalid Target"). I understand you're suggesting those also get conveyed via a type-specific response.
One even more interesting case is when we don't have a response defined already (eg for Multicast Replication Control message). Then should we create a new type-specific response (eg Multicast Replication Control response) or should we use the generic response (to avoid creating new message types)?
Francois
. Francois Le Faucheur wrote: Tom,
On 9 Oct 2009, at 13:53, Tom Taylor wrote:
Please see below.
Francois Le Faucheur wrote:
including the ANCP list as others may be interested.
Francois
On 8 Oct 2009, at 16:53, Francois Le Faucheur wrote:
Hi Tom,
One question to better understand your proposal:
In http://www.ietf.org/mail-archive/web/ancp/current/msg00955.html you said:
"Given that that Command TLVs will be present only in a limited set of message types, and "Cmnd Nmbr" is not one of the fields defined within the Command TLV, I would also remove "Cmnd Nmbr" from Status-Info. It can always be specified as part of the failureresponse to a particular message type."
I am not sure how to read that.
Are you saying that the Cmnd Nb would not appear in the Generic Response message because if it is needed we woudl use a more specific Response message?
[PTT]
Yes, that's what I had in mind.
For the case of a negative response to a Multicast Replication Control message: are you proposing that the Generic Response message be used (and then would it not have to contain the "Cmnd Nb") or are you saying that we would then use a new "Multicast Replication Control Response" which woudl contain the Cmnd Nb?
[PTT]
I would recommend a response specific to Multicast Replication Control.
This seems in contradiction with your Email of 27/08/2009 which says:
* Change "Multicast Status" to "Generic Response".
* "I assume the text should really read that the receiver MUST send a Generic Response message with the appropriate contents if unable to execute the complete Multicast Replication Control message successfully."
So, I am a little confused, now.
Currently, the Multicast Status message can be used in many scenarios including in responses to:
* Multicast REplication Control request
* Admission Control message
* Bandwidth Reallocation
* Delegated Bw Query Request
* Multicast Flow Query
Could you recap briefly what message you are proposing be used instead in each of these cases?
I can see that it would make sense to have a Generic Response message to deal with a number of generic cases (such as when a message is not recognized, or invalid).
Other than that, the MUlticast Status message was pretty much used as a multi-purpose response already (only, limited to all multicast use cases).
Thanks
Francois
However, my E-mail of 27/08/2009 suggested adding a new sub-TLV to Status-Info. To quote from the earlier message:
*** command error
-- Needs a new Code value, so add
85 Command error
to base, and define in base a sub-TLV of Status-info to carry the sequence number of the command within the message. This sub-TLV could also carry an additional diagnostic code with its own IANA registry if people think it might be useful. Extensions would define the actual code values and add them to the registry. Likely candidates are some of the errors listed in section 4.4:
- Command not supported
- Flag set but not supported
- M Flag set, but no IP Source address provided
- Unsupported Address Family
- Unsupported address encoding
- Malformed flow address
- Multicast flow does not exist
Thanks
francois
On 6 Oct 2009, at 17:15, Tom Taylor wrote:
I'm very happy to do that. Then we can discuss the result.
Maglione Roberta wrote:
Hello Tom,
in my opinion instead of submitting a new individual draft you should update the current mcast draft and propose your changes as a new version of the draft:
draft-ietf-ancp-mc-extensions-01
Meanwhile I can update the protocol draft with the additional changes that you proposed.
Best Regards,
Roberta
-----Original Message-----
From: Tom Taylor [mailto:tom.taylor at rogers.com]
Sent: Tuesday, October 06, 2009 4:57 PM
To: Francois Le Faucheur IMAP; Maglione Roberta; Wojciech Dec
Subject: Changes to ANCP multicast
I made some major proposals regarding the ANCP protocol drafts at the end of
August but have had no feedback. I'm wodering if the best way forward, given all
I have in mind, is to submit a new draft-taylor-ancp-mc-extensions incorporating
all my proposals, to serve as a basis for discussion that people can relate to.
What are your views?
Tom
Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.
_______________________________________________ ANCP mailing list ANCP at ietf.orghttps://www.ietf.org/mailman/listinfo/ancp
|