Re: [Pals] WGLC comments on draft-ietf-pals-rfc4447bis

[Luca Martini <[e-mail]>]

On 07/14/2015 11:54 AM, Stewart Bryant wrote:
> Here are my WGLC comments on draft-ietf-pals-rfc4447bis-01.txt
>
>
> SB> You should note in the metadata, abstract and intro that this
> SB> obsoletes RFC4777
That should be there , if it did not work it's just a bug in the nroff
script. The RFC editor will fix this if I rev it , i'll fix it.

>   Abstract
>
>
> SB> You have a CW change that should be noted here.
We should note that this obsoletes 6723. it did not make the header.
we'll fix it.

 
>  
>
> 1. Introduction
>
> SB> This is the original intro. A number of things have moved
> SB> on and people are more familiar with the technology
> SB> than when you first wrote this.
> SB> It is worth reflecting on whether this is still the
> SB> right introduction to use 10 years after publication
> SB> and 13 years since the first WG draft.
>
>
>     QoS-related issues are not discussed in this document.
>
> SB> QOS needs to be expanded.
No, I believe this is one of the terms that does not need expansion.
I'll leave it to the RFC editor's judgment.

>
>     For the purpose of this document, PE1 will be defined as the ingress
>     router, and PE2 as the egress router.  A layer 2 PDU will be received
>     at PE1, encapsulated at PE1, transported and decapsulated at PE2, and
>     transmitted out of PE2.
>
> SB> Of course it's not just L2 packets - since you have IP PWs
> SB> and I am not sure that TDM is really L2.
this is a nit. I do not think that changing this makes it better. In
fact i believe it makes it worse.
>   Note that this document was written to address errata in [RFC4447].
>
>
>
> 4. Details Specific to Particular Emulated Services
>
> 4.1. IP Layer 2 Transport
>
>     This mode carries IP packets over a pseudowire.  The encapsulation
>     used is according to [RFC3032].  The PW control word MAY be inserted
>     between the MPLS label stack and the IP payload.  The encapsulation
>     of the IP packets for forwarding on the attachment circuit is
>     implementation specific, is part of the native service processing
>     (NSP) function [RFC3985], and is outside the scope of this document.
>
> SB> You might consider just having section 4, rather than empty
> SB> 4 followed by small section 4.1
I like it this way.
>
>
> 6.2. PW Types for which the Control Word is NOT mandatory
>
> SB> NOT mandatory is not correct RFC2119 - I think you mean NOT REQUIRED

RFC2119 does not apply here.

>     If a system is capable of sending and receiving the control word on
>     PW types for which the control word is not mandatory, then each such
>     PW endpoint MUST be configurable with a parameter that specifies
>     whether the use of the control word is PREFERRED or NOT PREFERRED.
>
> SB> (NOT) PREFERRED are not RFC2119 complaint, we need to either use
> SB> RFC2119 terms of remove the capitals or put them in quotes
> SB> if the capitalization is formal notation.
We had a very long discussion on these terms 10 years ago, and I am not
about to change them or have another discussion now.
>     For each PW, there MUST be a default value of this parameter.  This
>     specification does NOT state what the default value should be.
>
> SB> I don't think NOT should be capitalised (same below)
>
>     If a system is NOT capable of sending and receiving the control word
>     on PW types for which the control word is not mandatory, then it
>     behaves exactly as if it were configured for the use of the control
>     word to be NOT PREFERRED.
>
> SB> 2119 again with NOT PREFERRED
>
rfc2119 does not apply here. The rule of this document is to highlight
the words PREFERRED, and NOT PREFERRED.
if you invent bold asci font i'll use it .... otherwise it's capital.
>
>
>
>
>
>
> 9. Changes from RFC4447
>
>     The changes in this document are mostly minor fixes to spelling and
>     grammar, or clarifications to the text, which were either noted as
>     errata to RFC4447 or found by the editors.
>
>     However a new section (6.3) on control-word renegotiation by label
>     request message has been added, referencing RFC 6723.   The diagram
>     of C-bit handling procedures has also been removed, as the updated
>     diagram in RFC 6723 is now definitive.
>
> SB> This should be reflected in the Abstract, and probably moved up to
> SB> the introduction, or at least a pointer placed in the introduction.
>
I believe that this should be removed by the RFC editor , so there is no
point in moving it.
This section was to point out to the WG what the changes where , not for
the RFC reader later...

>
>
>
> 14. Additional Historical Contributing Authors
>
>
> SB> It is convention to put additional names before the authors/editors
> SB> so that that the authors are at the end of the document.
> SB>
> SB> In many cases we know that the original authors have changed
> SB> their details, and I wonder whether it would not be appropriate
> SB> to at least say "now at foo corp, email address bar"
Maybe I should make this as an historical note ?
it's might be quite a task to track down the current addresses, and the
current affiliations might not be relevant.

Thanks.
Luca

> - Stewart
>
>
>
> _______________________________________________
> Pals mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pals