Ben - Inline.
> -----Original Message----- > From: Benjamin Kaduk <ka...@mit.edu> > Sent: Friday, June 12, 2020 9:15 PM > To: Les Ginsberg (ginsberg) <ginsb...@cisco.com> > Cc: The IESG <i...@ietf.org>; draft-ietf-isis-te-...@ietf.org; lsr- > cha...@ietf.org; lsr@ietf.org; Acee Lindem (acee) <a...@cisco.com>; > aretana.i...@gmail.com > Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with > DISCUSS and COMMENT) > > On Fri, Jun 12, 2020 at 07:45:00PM +0000, Les Ginsberg (ginsberg) wrote: > > Ben - > > > > Top posting the open issues - as I think there are only two. > > > > Issue #1 > > > > > > What is the scope over which the user-defined application bits are > > > > defined/allocated? > > > > > > > LES: User defined applications are - by definition - outside the scope of > > this > document/standardization. > > Yes. > > > We have simply defined the syntax of how to advertise associated bit > mask. > > But if my implementation is built around (say) the meanings of the bits in > the bit mask being local to a single area, and your implementation is built > around them having meaning local to a full domain, when you try to send me > something from out of area it's not going to work so well. Even without > saying what any given bit means, we can still say that "all systems in the > same <X> need to interpret each bit in the same way. What is the smallest > <X> such that deployment is safe? > > > How, for example, interoperability is achieved is up to implementors. > > Whether they want an application to be area scoped or domain-wide is also > up to them. > > I think leaving the question of area vs. domain up to the application is a > recipe for interop failures. > > (A similar question presumably applies to the OSPF document, though I > didn't get a chance to actually review that one.) > [Les:] If interoperability between implementations is a concern, then the obvious choice is to use a standardized application. Placing limits on the scope of a user defined application is both unnecessary and unenforceable. I say "unenforceable" because, if you have a mixed vendor network, there is no guarantee that User Bit X means the same thing to both implementations. And since I cannot tell the identity of the implementation originating an advertisement, I cannot tell if the User Bit advertised in Area Scoped LSPs (Level-1 in IS-IS speak) has the same meaning as the same bit advertised in Domain-wide LSPs. So I cannot detect when a violation occurs. To me, User Defined Application is a space for implementations to do whatever they choose - subject to the syntax rules defined in the draft. Maybe they use it as an experimental space for something they will eventually standardize. Maybe they use it to implement a proprietary application that they have no intention of standardizing. As it does not impact operation of the standard applications, I see no reason or benefit for the draft to impose restrictions. As context, User Defined was added based on comments received from some WG members. It isn't needed to support the goals of the draft. It is an option that at least some members felt was desirable to have. > > Issue #2 > > > > > > Section 7.4 > > > > > > > > > > > > > > policy for this registry is "Standards Action" [RFC8126]. Bit > > > > > > > definitions SHOULD be assigned in ascending bit order beginning with > > > > > > > Bit 0 so as to minimize the number of octets that will need to be > > > > > > > transmitted. The following assignments are made by this document: > > > > > > > > > > > > > > I worry a little bit that this will encourage codepoint squatting, > > > > > > > though in theory the user-defined bitmask should avoid the need for > > > > > > > squatting. > > > > > > > > > > > You replied: > > > > " If everyone expects a sequential allocation policy, then when > > developing/testing, it's natural to look at "what's in the registry now" > > and write code that uses the next value. If three people do that at the > > same time, we can end up with deployed software that has conflicting > > interpretation of that value. (This has happened for TLS, yes, with three > > different extensions using the same value.) My suggestion would be to > not > > say "SHOULD be assigned in ascending bit order", and perhaps just note > > (without normative language) that it is advisable to allocate from the > > lowest byte that has bits remaining, to allow for compact encoding. It's > > not actually necessary to be strictly sequential in order to minimize the > > number of octets transmitted." > > > > LES: I understand this concern. How about if we change policy to "Expert > Review"? > > I think that's moving on an orthogonal axis -- the TLS registry where we > had three extensions squatting on the same codepoint is a registry with > expert review. (My expectation is that Standards Action is actually safer > in this regard than Expert Review would be, since there's enough points of > coordination in the process of advancing a standard that someone is likely > to notice the issue, but I don't have any hard data or proof to support > that expectation.) > [Les:] Standards action is limited (by https://tools.ietf.org/html/rfc8126#section-4.9 ) to Standards track and BCP. This does not allow for Experimental track. So I think it is better to move to "Expert Review". > To throw another concrete suggestion out there for focusing comments, > perhaps > > OLD: > > Bit > definitions SHOULD be assigned in ascending bit order beginning with > Bit 0 so as to minimize the number of octets that will need to be > transmitted. > > NEW: > > Allocating all bits from the first octet before allocating any bits from > the second octet, etc., provides for the smallest possible encoding when > transmitted. [Les:] OK. How about: "Bit definitions SHOULD be assigned such that all bits in the lowest available octet are allocated before assigning bits in the next octet. This minimizes the number of octets that will need to be transmitted." ?? Les > > (After all, who is supposed to adhere to the original's "SHOULD"? The IETF, > as it undertakes its Standards Actions? Our track record on one RFC > constraining what future RFCs do is hardly perfect.) > > -Ben _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
