Re: [Isis-wg] Alvaro Retana's No Objection on draft-ietf-isis-auto-conf-04: (with COMMENT)

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

Alvarao -

> -----Original Message-----
> From: Alvaro Retana (aretana)
> Sent: Friday, April 07, 2017 2:26 PM
> To: Les Ginsberg (ginsberg); The IESG
> Cc: [e-mail]; Hannes Gredler; [e-mail];
> [e-mail]
> Subject: Re: Alvaro Retana's No Objection on draft-ietf-isis-auto-conf-04:
> (with COMMENT)
> 
> On 4/7/17, 5:09 PM, "Les Ginsberg (ginsberg)" <[e-mail]> wrote:
> 
> Les:
> 
> Hi!
> 
> …
> > > (2) What about the other bits in the Flag field, how should they be
> > > registered in the future (if needed)?  Please ask IANA to define a registry
> for them.
> > >
> > [Les:] I don't think a registry is needed. If an additional flag is
> > required then a bis draft will be required.
> 
> No.  That’s the point of specifying how others may request a flag in a registry:
> then they can go to IANA and not touch your document.
> 
> If I try to read between the lines…it sounds like you’re saying that the TLV
> would have no other use than for auto-configuration, so if any new flag is to
> be assigned it would necessarily have to modify this document.  Is that what
> you mean?
> 
> Honestly, I think it is just good practice to define how the remaining bits
> should be assigned/or not in the future.  But I’ll let the responsible AD make
> the call. ;-)
> 

[Les:] There are other examples of flags fields in IS-IS:

RFC 5306 Section 3.2 Restart TLV
RFC 7981 Section 2 Router Capability TLV
draft-ietf-isis-segment-routing-extensions

We do not define an IANA registry for these - and I think with good reason.
These are NOT general purpose flags which anyone can make use of - they are directly tied to the functionality of the TLV/sub-TLV in which they appear. To add a flag means one is extending the feature described in the original specification - a bis draft is a MUST.

   Les

> 
> …
> > > (5) I thought the point of this document was for use in "unmanaged
> > > deployments.  It allows IS-IS to be used without the need for any
> > > configuration by the user."  But Section 3.5. (Additional IS-IS TLVs
> > > Usage
> > > Guidelines) has recommendations for configuration options, including
> > > manually configured adjacencies (which should not be allowed
> > > according to Section 3.4.2. (Adjacency Formation)).  Isn't this
> > > against the stated reasons for this document?
> > >
> > [Les:] The mention of "manually configured adjacencies" is in the
> > context of what the default metric should be for non-manual adjacencies.
> > We do not recommend manual configuration, but it is not illegal to do it.
> 
> Would manual configuration unset the A flag because now the node is not
> acting in auto-configuration mode?
> 
> I know some of this was discussed on the list before, but if partial manual
> configuration is allowed (and the A flag is still set), what prevents a manually
> configured router from setting the A flag and if the parameters (area, level,
> etc.) match, form an adjacency?  There was a discussion about not allowing
> non-auto-configured routers and auto-configured ones from becoming
> adjacent.
> 
> 
> > > (6) Authentication is one of those features that could be manually
> > > configured
> > > -- but the default is no authentication.  There's a
> > > higher-than-usual risk of a node listening on the network (probably
> > > a bigger problem for the user traffic), but also one that could
> > > listen to the Hellos and purposefully trigger the duplicate
> > > resolution mechanism to continuously run.  This risk should be
> > > highlighted in the Security Considerations because it is newly
> > > introduced here. [Robert Sparks pointed this risk out during his
> > > GenArt review.]
> > >
> > [Les:] Let me know if the answer I provided to Robert suffices.
> 
> No.  I would have the same answer that he did: you should describe the new
> risk.  But let’s keep the discussion on that thread.
> 
> Thanks!
> 
> Alvaro.