Re: [Pals] Benoit Claise's No Objection on draft-ietf-pals-status-reduction-04: (with COMMENT)

[Luca Martini <[e-mail]>]

Benoit,
Comments inline
Thanks.
Luca

On 04/10/17 08:22, Benoit Claise wrote:
> Benoit Claise has entered the following ballot position for
> draft-ietf-pals-status-reduction-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-pals-status-reduction/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> As mentioned by Jürgen in his OPS-DIR review:
>
> Section 1.2 is not really about terminology but instead it basically
> expands acronyms. The section does not define any terms or does it
> make it clear where terms are defined. A reader who does not know
> T-PE
> will not be pointed to a document that defines 'Terminating Provider
> Edge Node of MS-PW'. I usally find terminology sections more useful
> if
> they say where definitions of terms get be found.
>
> Section 3: s/the the/the/
>
> Section 4: What is the 'Version' field in the message format?
as the text says :  explained in [RFC5586]
> Section 4: There is an 8-bit field marked U C Flags and I _assume_
> the
> U and C bits are the 'first' two bits and the 'remaining bits are the
> flags managed by IANA. Perhaps make this clearer, e.g.:
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Last Received Seq Number     | Message Type  |U|C|   Flags   |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
yes - the ascii art was incorrect.

> Or alternatively simply name the entire 8-bit flags field like you do
> in the text where you refer to Message Flags and then explain in the
> text under the 'Message Flags' that the first two bits have a fixed
> meaning.
>
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>    |  Last Received Seq Number     | Message Type  | Message Flags |
>    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
> This option carries less information but then you use 'Message Flags'
> in several places and you also request an IANA registry for Message
> Flags where the U and C bit are allocated. Looking at the IANA text,
> it says 'bit position' 0 and 1. Not sure this is clear enough, you
> seem to number bits in the order 0, 1, 2, ...
>
> It turns out we have several slightly different labels further down
> in
> the document for this flags field throughout the document - this
> makes
> searching in the text difficult, please use a single consistent name
> for this message field.
>
Yes! thanks for catching this. We suffer from multiple editor syndrome ;-)
> Section 8.2 says values 1 and 2 are defined in this document but then
> it seems value 3 is also allocated, no?
yes - fixed.
> Subsections of section 8 switches several times between decimal and
> hexadecimal numbers. Perhaps things get clearer if a single number
> system (e.g., hexadecimal) is used when talking about a specific
> registry. Numbers like 134,217,728 look somewhat confusing, 0x8000000
> seems simpler.
>
>
I would have kept it all in hexadecimal format , but somehow I think
someone asked for the text to be decimal.
IANA already processed this , so I would like to leave it as is.

Thanks.
Luca