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

Hi Alvaro and Les,

Thanks for your comments.

> Suggestion: include the 1 octet "flags field" in the drawing -- if 
> needed, then show the detail (where the S and A bits are) in the description of the field.
> 
[Les:] Bing has the pen - I will let him respond - but I am OK with your suggestion.

No problem, I'll do it in the next version.

Best regards,
Bing

> -----Original Message-----
> From: Isis-wg [mailto:isis-wg-bounces@ietf.org] On Behalf Of Les Ginsberg
> (ginsberg)
> Sent: Saturday, April 08, 2017 5:09 AM
> To: Alvaro Retana (aretana); The IESG
> Cc: draft-ietf-isis-auto-conf@ietf.org; isis-chairs@ietf.org; isis-wg@ietf.org
> Subject: Re: [Isis-wg] Alvaro Retana's No Objection on
> draft-ietf-isis-auto-conf-04: (with COMMENT)
> 
> Alvaro -
> 
> Thanx for the review.
> Inline.
> 
> > -----Original Message-----
> > From: Alvaro Retana (aretana)
> > Sent: Friday, April 07, 2017 1:31 PM
> > To: The IESG
> > Cc: draft-ietf-isis-auto-conf@ietf.org; Hannes Gredler;
> > isis-chairs@ietf.org; isis-wg@ietf.org
> > Subject: Alvaro Retana's No Objection on draft-ietf-isis-auto-conf-04:
> > (with
> > COMMENT)
> >
> > Alvaro Retana has entered the following ballot position for
> > draft-ietf-isis-auto-conf-04: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-isis-auto-conf/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > I have a series of comments -- they don't add up to a DISCUSS, but I
> > think it is important that they are solved before publication.
> >
> > (1) In Section 3.3. (Router-Fingerprint TLV), the format presented
> > doesn't actually show the "flags field", which is described in the text,
> > but it shows its contents.   The length is defined as "the length of the
> > value field", but the figure doesn't explicitly show the Value field.
> > It is probably obvious that the flags field + Router Fingerprint =
> > Value, but it would be nice to be specific.
> >
> > Suggestion: include the 1 octet "flags field" in the drawing -- if
> > needed, then show the detail (where the S and A bits are) in the description
> of the field.
> >
> [Les:] Bing has the pen - I will let him respond - but I am OK with your
> suggestion.
> 
> >
> > (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.
> This is no different than many other flags fields already defined in the
> protocol.
> Note that this is different than (for example) the flags field in RFC 7794 since
> it is a fixed size.
> 
> 
> > (3) Section 3.1. (IS-IS Default Configuration) mentions several TLVs
> > that MUST NOT be used...and Section 3.3. (Router-Fingerprint TLV) says
> > that this TLV MUST NOT be included in an LSP with a non-zero LSP
> > number.  What should a receiving node do if any of those conditions are
> not true?
> >
> [Les:] Ignore on receipt. We can add an explicit statement.
> 
> > (4) s/3.4.3.  IS-IS System ID Duplication Detection and Resolution/3.4.3.
> >  IS-IS System ID Duplication Detection
> >
> [Les:] Agreed.
> 
> > (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.
> 
> > (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.
> 
>    Les
> 
> 
> 
> _______________________________________________
> Isis-wg mailing list
> Isis-wg@ietf.org
> https://www.ietf.org/mailman/listinfo/isis-wg