Re: [Lsr] Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with DISCUSS and COMMENT)

["Les Ginsberg (ginsberg)" <[e-mail]>]

Ben -

V16 has been published addressing your comments on the new registry.

At this point I am not planning any additional changes to the document.

If you still want to discuss UDA related issues (or anything else), please let me know.

Thanx.

    Les


> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]>
> Sent: Saturday, June 13, 2020 12:03 PM
> To: Les Ginsberg (ginsberg) <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail]; lsr-
> [e-mail]; [e-mail]; Acee Lindem (acee) <[e-mail]>;
> [e-mail]
> Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-isis-te-app-14: (with
> DISCUSS and COMMENT)
> 
> Also inline.
> 
> On Sat, Jun 13, 2020 at 05:01:41PM +0000, Les Ginsberg (ginsberg) wrote:
> > Ben -
> >
> > Inline.
> >
> > > -----Original Message-----
> > > From: Benjamin Kaduk <[e-mail]>
> > > Sent: Friday, June 12, 2020 9:15 PM
> > > To: Les Ginsberg (ginsberg) <[e-mail]>
> > > Cc: The IESG <[e-mail]>; [e-mail]; lsr-
> > > [e-mail]; [e-mail]; Acee Lindem (acee) <[e-mail]>;
> > > [e-mail]
> > > 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.
> 
> I see your point about being able to "detect a violation".  That you are
> focusing on this aspect makes me suspect that my point did not come across
> quite as intended, though.  I don't feel a need to make a normative
> statement like "User Bits MUST be agreed upon at Domain-wide scope",
> since
> if anything that's trying to place a requirement on the operator, and our
> role is mostly just to inform the operator so they can make their own
> decisions.  As such, I'd be thinking more along the lines of "when
> user-defined bits are used, all routers that receive such information have
> to agree on their meaning, or breakage can occur.  Minimally, this implies
> that all machines in a given area need to use the same mapping of user-bit
> to application, and it's safest to ensure agreement across the entire
> domain."  (But with more wordsmithing, of course.)
> 
> > 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.
> 
> It's also interesting to me that you are picturing this as a
> per-implementation thing -- the "user" in the name had me expecting it to
> be something that implementations expose as a configuration knob, so that
> the operator would control what bit maps to which application.  If there is
> such a configuration knob then our guidance to the operator gains
> importance; if not, then any discussion of how to choose user-bits would
> only be targetted to the implementation, in which case your stance of not
> saying anything makes a fair bit of sense.
> 
> > 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.
> 
> It does seem useful to me, to have a defined path for experimentation that
> cannot conflict with the standards-assigned space.
> 
> >
> > > > 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."
> >
> > ??
> 
> Ship it :)
> 
> Thanks,
> 
> Ben
> 
> >    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