Re: [Pals] RtgDir review of draft-ietf-pals-status-reduction-01.txt

["BRUNGARD, DEBORAH A" <[e-mail]>]

Much thanks Adrian for your very careful review - and thanks Luca for picking up the pen on this long standing unprovisioned document:-)

Below, answers for AD items, and a couple of others which I could not resist.

Deborah

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: Monday, February 13, 2017 1:59 PM
> To: 'Luca Martini' <[e-mail]>; 'Andrew G. Malis'
> <[e-mail]>; 'George Swallow' <[e-mail]>; 'Elisa
> Bellagamba' <[e-mail]>
> Cc: [e-mail]; [e-mail]; BRUNGARD,
> DEBORAH A <[e-mail]>; [e-mail]
> Subject: RE: RtgDir review of draft-ietf-pals-status-reduction-01.txt
> 
> Hi Luca,
> 
> Love monoski.com!
> 
> You've done a fine job with this. Thanks.
> 
> Just cutting down to a few minor points that are so trivial I'm ashamed to
> type...
> 
> > >     > Section 4
> > >     > You have not described all of the fields in the figure.
> > >
> > What did I miss ?
> 
> -  MPLS LSP (tunnel) Label Stack Entry
> -  GAL
> - 0 0 0 1
> - Version
> - Reserved
> 
> But these probably only need a group entry pointing at another doc.
> 
> > >     >
> > >     > Section 4
> > >     > You have...
> > >     > Channel type 0xZZ pending IANA allocation.
> > >     > ...but no mention in the IANA section
> > >     > The figure shows "0xZZ PW OAM Message", but surely this is
> > >     > "PW Status Reduction Message"
> > >     >
> > >
> > Sure , but it has not been allocated yet. This is for the RFC editor to
> > replace the text once the allocation is dune.
> 
> Yeah, but if you don't have 0xZZ or "PW OAM Message" in the IANA
> Considerations section (section 8) it seems unlikely that IANA will do anything
> and so the RFC Editor will not be able to replace ZZ with anything.
> 
[deborah] Agree with Adrian.

> > >     > Section 4
> > >     > Do you want IANA to track the flags field?
> > no.
> > I think this needs to be allocated by a new RFC. Is that not the default ?
> > Making flags easy to allocate when there are only 6 bits is not wise and
> > will lead to misuse.
> 
> You would still need an RFC to allocate the flags.
> The difference is that, without the registry, several RFCs may become
> "confused" about which flags they have allocated.
> The IANA registry provides a way of preventing clashes.
> 
[deborah] Agree with Adrian.

> > >     > Section 5
> > >     > In 8.3 you list a number of notification codes. A little can be
> > >     deduced
> > >     > from their names, but you do not describe anywhere when or why
> > >     most of
> > >     > them are used (5.0.2.3 and 6 are the exceptions). You should, and
> > >     > section 5 or 6 is probably the place.
> > >
> > These are really obvious. I do not see the point of adding obvious text.
> > Go look at all the BGP specs , most of them are extremely unreadable,
> > this is much more clear then any of those.
> > like if i receive an ack message sequence number that is after the last
> > message i sent , clearly is have a "Unacknowledged control message" error...
> 
> Ah, and there was I thinking that this would be a "Control message
> acknowledgement" error, while "Unacknowledged control message" would be
> used when a control message went unacknowledged. :-)
> 
> I don't think "other documents are worse" is the best argument you've ever
> used, but I'm not going to fight this. It's up to the AD and shepherd.
[deborah] 
Agree with Adrian - half of these are noted in the appropriate section, so it's only a couple of them which still need to be added.
> 
> > >     > Section 8.1
> > >     > You have a range assigned by Expert Review. It is a requirement that
> > >     > you give guidance to the experts about how they should review
> > >     > requests.
> >
> > we did not do that in the past.  I assume that the Expert is an Expert
> > in this field , and has good judgment.
> > maybe i should add "at sole discretion of the expert" ?
> 
> Times may have changed.
> Let's leave this for the AD to worry about.
[deborah] 
As Adrian noted, much more is needed to guide when using "Expert review". In 5226bis,  RFC7752 is given as an example for reference. But I'm wondering, why not use "IETF review"? It's used for other G-ACh types. Check with your Chairs.
> 
> > >     > Section 8.1
> > >     > The values 128 through 254 are assigned using FCFS. You cannot then
> > >     > attempt to further constrain how the values are used (e.g., "for
> > >     vendor
> > >     > proprietary extensions"), and you should avoid the word
> > >     "reserved" since
> > >     > it has special meaning for IANA.
> > >
> > ??? i want the vendor proprietary extensions to be FCFS, does this not
> > say that ?
> > the point is that if something is not a proprietary extension it should
> > not use this.
> > for example it prevents people like me from using FEC type 128 for a
> > standard protocol ...;-)
> 
> Afraid it doesn't
> FCFS means "open season". Anyone can get a FCFS code point for any use.
> Again, the AD can help sort this out.
[deborah] 
As Adrian says, FCFS doesn't have any restrictions (5226bis).
> 
> > >     > The sub-section numbering in Section 5 is broken. You can have,
> > >     > for example, "5.0.1".
> > >     >
> > >
> > fixed
> > >
> > >     > In a number of places you have "sub-TLVs" and in other places
> > >     "TLVs".
> > >     > I think they are all "TLVs".
> > >
> > yes, i mean sub-tlv because it's within another tlv.
> >
> >
> > >     > In 5.0.2.1 "the address of the MPLS-TP tunnel ID" is confused. It is
> > >     > "the identifier of the MPLS tunnel". Indeed, where did MPLS-TP
> > >     suddenly
> > >     > come from since you want this to work for all LSPs (see also 8.2).
> > >     >
> > >
> > no, this is what this is . If you want an MPLS tunnel ID , it would be
> > different.
> 
> Shrug.
> I don't think it's an address. I think its and ID.
[deborah] 
Agree with Adrian - it's an ID. One can use an IP address for it, but it's an ID (RFC6370). In this section (5.2.1), several MPLS/s/MPLS-TP needed.
> 
> > >     > 2.1.1, 2.1.3, and 5.0.2.3
> > >     > "unprovisioned"
> > >     > I think the word is "deprovisioned"
>  >
> > unprovisioned means it is not provisioned. deprovisioned , i take to
> > mean that it was once provisioned, now it is not ....
> > I like the more generic "unprovisioned"
> 
> Hmmm. The phrase would be "not provisioned".
> "unprovisioned" apparently gives rise to confusion :-)
> 
[deborah] 
Looking at 5.2.3, it says "a list of the PWs that have been unprovisioned on the LSP." So this is confusing, as Adrian says, it infers they have been "deprovisioned". If they have not been provisioned, the sentence would say (to me), "that are unprovisioned on the LSP" ("are" is also used in the rest of the document). So to me, if fix this sentence to "are", and at the first use of "unprovisioned" in the document, put "(not provisioned)", it should be clear. Then hopefully "unconfigured" is not confusing:-) And I'm sure during IESG review, we will hear if others find it not un-confusing.