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.