Re: [Idr] Review of draft-ietf-large-community-06

[Mach Chen <[e-mail]>]

Hi Job,

Thanks for your prompt response!

Please see replies inline...

> -----Original Message-----
> From: Job Snijders [mailto:[e-mail]]
> Sent: Tuesday, November 08, 2016 7:26 PM
> To: Mach Chen
> Cc: IETF IDR WG
> Subject: Re: [Idr] Review of draft-ietf-large-community-06
> 
> On Tue, Nov 08, 2016 at 06:22:54AM +0000, Mach Chen wrote:
> > I have review the latest version(06) of this document. The draft is
> > well written and is basically ready for publication. I have some minor
> > comments as bellows:
> >
> > 1.
> >
> > Section 2, the first sentence:
> > "This document creates the Large BGP Communities attribute as an..."
> >
> > Although RFC1997 also uses "creates", I'd suggest to use "defines"
> > here, it also aligns with the convention of most of the RFCs.
> 
> Good suggestion, accepted.
> 
> > 2.
> > Section 2, the last sentence:
> > "A receiving speaker SHOULD silently remove duplicate Large BGP
> > Communities from a BGP UPDATE message."
> >
> > IMHO, whether remove the duplicate communities from a BGP UPDATE
> > message is not significant, since the life of the message is over once
> > the message processed. The key point is that the receiving speaker
> > should ignore the duplicate Large BGP Communities.
> >
> > How about:
> >
> > "A receiving speaker SHOULD silently ignore the duplicate Large BGP
> >    Communities within a Large BGP Communities attribute. "
> 
> After the latest round of review from Geoff Huston and Jakob Heitz the
> following text was produced.
> 
> The below text is queued to be in -07 of the draft, but -07 can't be posted yet as
> we are in the 'cutoff' period before the IETF meeting in Seoul.
> 
> """
> 	Duplicate BGP Large Community values SHOULD NOT be transmitted. A
> 	receiving speaker SHOULD silently remove duplicate BGP Large
> 	Community values from a BGP Large Community attribute.
> """
> 
> I think the above text aligns with your suggestion, right?

Yes, I am fine with the text.

> 
> > 3.
> >
> > In Section 5 says:
> >    "Operators SHOULD NOT use these Global Administrator values."
> >
> > Later, in Section 6:
> > "The Large BGP Communities Global Administrator field may contain any
> > value, and a Large BGP Communities attribute MUST NOT be considered
> > malformed if the Global Administrator field contains an unallocated,
> > unassigned or reserved ASN or is set to one of the reserved Large BGP
> > Community values defined in Section 5."
> >
> > The "SHOULD NOT", "may contain any value" and "MUST NOT" seems little
> > bit confusion and self-contradiction. Since the first sentence is not
> > a specification to the Large BGP Communities attribute, but just a
> > recommendation to the Operators.
> >
> > How about changing it as:
> >
> > "It is recommended that operators do not use these Global
> > Administrator values."
> >
> > Or using some other similar text.
> 
> I don't see the contradiction, its text that gradually narrows down into specifics
> for specific audiences. The text in section 5 is for operators, the text in section
> 6 is for implementors and bgp developers.
> I don't think that removing the 2119 language will increase the clarity.

Although I am not fully convinced, I am OK to move the document forward and let's leave this to the picky IESG review :-)

Best regards,
Mach
> 
> > Hope this comments helps!
> 
> Very much appreciated!
> 
> Kind regards,
> 
> Job