Hi Alvaro, Version -11 of this draft has been posted which is intended to resolve your DISCUSS.
Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA [email protected] On Thu, Jul 7, 2016 at 6:51 AM, Alvaro Retana (aretana) <[email protected]> wrote: > On 7/7/16, 1:16 AM, "Donald Eastlake" <[email protected]> wrote: > > Donald: > > Hi! > > >>---------------------------------------------------------------------- > >> DISCUSS: > >> ---------------------------------------------------------------------- > >> > >> Even though the IANA Considerations section was just updated (in version > >> -10), I am putting in this DISCUSS because it is still > >> incomplete/incorrect. > >> > >> 1. Guidance for managing the SubERR namespace should be included. Note > >> that this document only specifies values for ERR 6, but guidance should > >> be given to IANA for the other ERR values as well. > > > >No IANA registry is created for any SubERR values so I'm not sure why > >there needs to be IANA guidance. The draft can be made clearer that > >for all values of ERR other than 6, SubErr should be sent as zero and > >ignored on receipt. If you want, a registry could be added. I would > >think IETF Review was the appropriate registration procedure. > > Yes, I think a registry should be added. > > > > >> 2. Section 6.2.1 (RBridge Channel Error Codes Subregistry) requests the > >> creation of a new registry ("RBridge Channel Error Codes²), but that > >> registry was already created by RFC7178. This document should then > >>split > >> the requests in two parts: assignment of the vales 6-8, and the change > >>to > >> the registration procedure. > > > >You are correct. Sorry for the oversight. > > > >However, I actually think the registration procedure should stay as > >Standards Action for new ERR codes as provided in the current IANA > >registry.New major error codes can cause substantial problems with > >older implementations that do not know what they mean. (I do not think > >this is a problem with SubErr since implementations can take a default > >action based on the major ERR code.) > > That works for me; I just mentioned the registration procedure because it > had been changed. > > > > > >> ---------------------------------------------------------------------- > >> COMMENT: > >> ---------------------------------------------------------------------- > >> > >> >From Section 2. (RBridge Channel Header Extension Format), is the RESV4 > >> field a space that is reserved for potential future use? Why isn¹t it > >> ignored on receipt (similar to the RESV field in Section 4.3)? If there > >> is potential for use of this space (RESV is defined as 4 bits, which > >> makes me think about potential bit-level allocations), then there should > >> be some guidance in the IANA Considerations. > > > >Earlier versions of this document added three features to RBridge > >Channel. As well as the payload feature and security feature in the > >current document, which are invoked by non-zero values of the PType > >and SType nibbles, > > if you look at the -01 or -00 version you will see a "Scope" > >feature invoked by non-zero values of the Scope nibble. RBridge > >Channel supports messages between RBridges in the same TRILL campus > >and between an end station and an RBridge on the same link. The Scope > >feature extended this to support, for example, messages between an end > >station and an RBridge not on the same link. However, the scope > >feature added significant complexity and there was no immediate > >requirement for it so it was dropped and the Scope nibble was > >relabeled RESV4. > > Those bits are deliberately made "critical" so the Scope feature > >could be revived in the future and Scope-ignorant RBridges would know > >to reject Extended RBridge Channel messages that are using the Scope > >feature which changes the format a little. Any attempt to re-instate > >the Scope feature or to make other use of these four bits will require > >a Standards Track document in any case. I don't understand why there > >needs to be any guidance in the IANA Considerations about this. What > >would it say other than that any non-zero value is treated as an > >error? which is a technical specification already present in the body > >of the document and not an IANA Consideration. > > I agree with you on the IANA part (no need to add anything related to > RESV/RESV4). > > I still think (non blocking comment) that treating a received non-zero > value as an error adds unnecessary complexity if it can just be ignored. > If the Scope feature is ever revived (or any other feature that wants to > use the field) then it can change the behavior then. > > Thanks! > > Alvaro. > >
_______________________________________________ trill mailing list [email protected] https://www.ietf.org/mailman/listinfo/trill
