Subject: Re: [RTG-DIR] Routing Directorate review of draft-ietf-pals-rfc4447bis

From: "Giles Heron (giheron)" <[email-masked]>
Date: Thu, 5 May 2016 11:11:18 +0000

Hi Adrian/Luca,

sorry for the slow response on this.

We may need to iterate one more time too :(

> On 21 Feb 2016, at 15:16, Adrian Farrel <[email-masked]> wrote:
> 
> Hello, 
> 
> I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir 
> 
> Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them as the draft advances, and strive to resolve them through discussion or by updating the draft. 
> 
> Thanks,
> Adrian
> 
> ===
> 
> Document: draft-ietf-pals-rfc4447bis-03.txt 
> Reviewer: Adrian Farrel
> Review Date: 21 February 2016
> IETF LC End Date: Not yet started
> Intended Status: Internet Standard
> 
> = Summary =
> 
> I have some minor concerns about this document that I think should be resolved before publication. 
> 
> = Comments =
> 
> I'm OK to see 4447 being advanced to full standard, although I'm also a little surprised that there was energy to do it.
> 
> The work is largely mechanical. My comments are a mix of minor process concerns (that your AD should be able to resolve), minor text clarifications, and nits.
> 
> It's been a while since I was concerned with LDP, but I have no reason to doubt the integrity of this document.
> 
> = Major Issues =
> 
> No major issues found. 
> 
> = Minor Issues =
> 
> I believe that this document should be marked as obsoleting 4447 and 
> 6723. It will result in a new RFC with a new number, so 4447 will no
> longer be relevant. And, as Section 1 says: a new section (6.3) on 
> control-word renegotiation by label request message has been added,
> obsoleting RFC 6723.

it is marked that way.  but it’s only when it goes to RFC that that gets into the text?

> By the way, it is section 7.3 (not 6.3) that you have added!

thanks!  will fix :)

> [NB: Q16 of the Shepherd write-up seems a bit garbled on this front.
> Especially "Will publication of this document change the status of any
> existing RFCs?" seems to need a much clearer answer!]

:)

> ---
> 
> I'm not up to speed on the new process for advancing a specification to
> Internet-Standard when it has normative references that are not 
> similarly advanced/advancing. I do know that the process changed
> recently and I am sure that your AD can look it up.

I wait with bated breath ;)

> ---
> 
> It might be a reasonable question to ask why some of the
> (informatively) referenced related PW RFCs (such as encapsulations)
> are not being advanced at the same time, especially those that are
> described as "companion documents”.

RFC4447-bis is being done because there were too many errata on 4447.   There won’t as many on the others.  I think the promotion to Internet Standard happened as part of that?
 
> ---
> 
> It seems unnecessary petty-fogging process, but the inclusion of
> section 7.3 seems to me to defeat the stability requirement for
> advancement to Internet Standard unless your claim here is that you
> are advancing 4447 and 6723 together in this single document. That
> might be fine.

the issue is that 4447 failed to cover a corner-case that was documented in 6723.   So 6723 could be seen as a super-erratum on 4447.  4447bis merges it in as a single document.

> ---
> 
> The Errata that have been deliberately disregarded need to be marked as
> Rejected. I think the ones that have been actioned could usefully be 
> marked as Verified or have a note added saying "fixed in RFCabcd".
> 
> As far as I can tell:
> 
> 3554 was not actioned

it was actioned, but with better wording (IMO) than the erratum

> 938 was done
> 86 was done
> 3555 was done
> 3115 no longer applies
> 3114 was done
> 3112 was done
> 1530 was done

yup.

> ---
> 
> Because you (incorrectly) said that section 6.3 was new text, I gave it
> careful review. I think the text is in rather poor state:
> 
> For example, in 6.3.1...
> 
>   Using the procedures
>   outlined in this section, a simple label withdraw method MAY also be
>   supported as a legacy means of signaling PW status and AC status.
> 
> ...Since this is *the* specification now, what does "legacy" mean?

it means for interop with extremely old implementations (implementations that were pre the 4447 standard).

> Indeed, you end 6.3.1 with...
>   The PW status
>   signaling procedures described in this section MUST be fully
>   implemented.
> ...which kind of implies ... hmm.

yes - they must be implemented.  But you can interwork with “legacy”.

> I think you could rework 6.3.1 to handle this more gracefully and avoid
> the "clunk" of the 2nd para...
> 
>   Once the PW status negotiation procedures are completed and if they
> 
> ...where we are surprised to hear about status negotiation.
> 
> For example:
> 
> OLD
>   The PEs MUST send Label Mapping Messages to their peers as soon as
>   the PW is configured and administratively enabled, regardless of the
>   attachment circuit state.  The PW label should not be withdrawn
>   unless the operator administratively configures the pseudowire down
>   (or the PW configuration is deleted entirely).  Using the procedures
>   outlined in this section, a simple label withdraw method MAY also be
>   supported as a legacy means of signaling PW status and AC status.  In
>   any case, if the label-to-PW binding is not available the PW MUST be
>   considered in the down state.
> 
>   Once the PW status negotiation procedures are completed and if they
>   result in the use of the label withdraw method for PW status
>   communication, and this method is not supported by one of the PEs,
>   then that PE must send a Label Release Message to its peer with the
>   following error:
> 
>   "Label Withdraw PW Status Method Not Supported"
> 
>   If the label withdraw method for PW status communication is selected
>   for the PW, it will result in the Label Mapping Message being
>   advertised only if the attachment circuit is active.  The PW status
>   signaling procedures described in this section MUST be fully
>   implemented.
> NEW
>   The PEs MUST send Label Mapping Messages to their peers as soon as
>   the PW is configured and administratively enabled, regardless of the
>   attachment circuit state.  The PW label should not be withdrawn
>   unless the operator administratively configures the pseudowire down
>   (or the PW configuration is deleted entirely). 
> 
>   Section 6.3.2 describes a mechanism for signaling the status of the 
>   PW and AC.  Additionally, a simple label withdraw method MAY be used 
>   to signal the PW status and AC status.  In any case, if the label-to-
>   PW binding is not available the PW MUST be considered to be in the 
>   down state.
> 
>   The PEs negotiate which PW and AC status signaling mechanism to use
>   by following the procedures in Section 6.3.3.  If the PW negotiation
>   procedures are completed and if they result in the use of the simple 
>   label withdraw method for PW status communication, and if this method
>   is not supported by one of the PEs then that PE must send a Label
>   Release Message to its peer with the following error:
> 
>   "Label Withdraw PW Status Method Not Supported"
> 
>   If the label withdraw method for PW status communication is selected
>   for the PW, it will result in the Label Mapping Message being
>   advertised only if the AC is active.
> 
>   The PW status signaling procedures described in Section 6.3.2 MUST be
>   fully implemented.
> END

I’m not sure we want to make big text changes at this stage for marginal benefit?

> ---
> 
> Section 6.3.2 achieves ambiguity by stating...
>   The general format of the Notification Message is:
> ...and then showing the specific case of "PW status".
> 
> You can fix this by re-ordering and tweaking slightly, as follows.
> 
> Note that the old text says:
>   Since this notification does not
>   refer to any particular message, the Message Id and Message Type
>   fields are set to 0.
> ...but I think the Message Type is set to 0x0001 :-)
> 
> 
> OLD
>   The Status TLV is transported to the remote PW peer via the LDP
>   Notification message.  The general format of the Notification Message
>   is:
> 
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |0|   Notification (0x0001)     |      Message Length           |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                       Message ID                              |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                       Status (TLV)                            |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                      PW Status TLV                            |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |           PWId FEC TLV or Generalized ID FEC TLV              |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |               PW Grouping ID TLV (Optional)                   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> 
>   The Status TLV status code is set to 0x00000028, "PW status", to
>   indicate that PW status follows.  Since this notification does not
>   refer to any particular message, the Message Id and Message Type
>   fields are set to 0.
> NEW
>   The Status TLV is transported to the remote PW peer via the LDP
>   Notification message as described in [RFC5036].
> 
>   The Status TLV status code is set to 0x00000028, "PW status", to
>   indicate that PW status follows.  The format of the Notification
>   Message for carrying the PW Status is as follows:
> 
> 
>    0                   1                   2                   3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |0|   Notification (0x0001)     |      Message Length           |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                       Message ID                              |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                       Status (TLV)                            |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |                      PW Status TLV                            |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |           PWId FEC TLV or Generalized ID FEC TLV              |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |               PW Grouping ID TLV (Optional)                   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
>   Since this notification does not refer to any particular message,
>   the Message Id field is set to 0.
> END

again I’m not sure I’d want to make major changes to the text if we can avoid it.

> ---
> 
> Section 8 could be tidied a little.
> 
> The use of "in general" gives the IANA no way to know whether they
> should or should not update a reference. 

I think maybe we just need a note asking IANA to remove this section once the RFC is published, and to update all the registries with the new number of this RFC?

> Are you sure that you want to remove the nice, concise listing of code
> points that are present in RFC 4447?

yeah - I think we removed them to avoid risk of contradicting the registry.

> 8.1, 8.2, and 8.3 all say "new". I suggest deleting that word.

ok - we’ll rely on IANA to do this :)

> And lastly, "IANA needs to..." is not what we say :-) "IANA is requested
> to..." is nicer.

hopefully my new wording for section 8 will be nicer :)

> [NB: The Shepherd write-up seems to report all this wrongly at Q17]
> 
> ---
> 
> Shouldn't the whole of Section 10 be moved to an interop report
> somewhere? It's presence within the document seems somewhat temporally
> unstable. I understand that you want to write it down and record it
> somewhere, also that you probably developed it in the I-D as a useful 
> place for working text. For advice about how and where to do this you
> can look at RFC 5657.

The AD asked us to put this in to provide evidence for moving to Internet Standard.  Happy to remove it again of course if the AD requests :)

> You seem to have answered the four points from 6410, but may be missing
> a little corroboration. 
> 
>> The pseudowire technology was first deployed in 2001 and has been
>> widely deployed by many carriers. [RFC7079] documents the results of
>> a survey of PW implementations, with specific emphasis on Control
>> Word usage.  [EANTC] documents a public multi-vendor interoperability
>> test of MPLS and Carrier Ethernet equipment, which included testing
>> of Ethernet, ATM and TDM pseudowires.
> 
> 7079 is a slightly related piece of survey work, but the only mention of 
> LDP (which is the subject of *this* document) is to point out an issue
> with non-implementation.

understood.  We were just trying to show that PW was widely implemented.

> The EANTC reference really needs something that helps us find the report
> of the interop event. Possibly this is
> http://www.eantc.de/fileadmin/eantc/downloads/events/2007-2010/MPLSEWC09/EANTC-MPLSEWC2009-WhitePaper-v1.0.pdf
> Looking at that paper, it definitely supports the claim of multiple
> interoperating implementations of 4447.

can we put URLs into references?  And can they be that long? ;)

> We lack, however, any statements about "widespread deployment and 
> successful operational experience.”

I put:  "The pseudowire technology was first deployed in 2001 and has been widely deployed by many carriers.”  I’m not sure what more we can do.   Provide lists of carriers offering services based on pseudowires?  That’d be *very* temporarlly unstable ;)

>> The errata against [RFC4447] are all editorial in nature and have
>> been addressed in this document.
> 
> Good (except for those not addressed as above, and except that some of
> those errata are incorrectly marked as "Technical”).

so they’re all addressed as noted above.  And we can say “mostly editorial”?

>> All features in this specification have been implemented by multiple
>> vendors.
> 
> How do we know this?

I’m really not sure how we prove that.

> Further, are all the features used? One point of this step in the 
> process is to prune out features that are unnecessary (and so complicate
> implementation and operation, and cost money).

right - so as far as we know all the features are in use by multiple vendors.  I’ve asked around inside Cisco to check our implementations, but I’m very happy for someone else to check with our competitors.

>> There is no IPR filed against this document or its predecessor.
> 
> This may be overly vague (you probably mean "No IPR disclosures have
> been made to the IETF related to this document, to RFC 4447 or RFC 6723,
> or to the Internet-Drafts that resulted in RFC 4447 and RFC 6723.”).

ok - will change.

> ---
> 
> = Nits =
> 
> In the Abstract, probably...
> 
> OLD
>   This document has been written to address errata in a previous
>   version of this standard.
> NEW
>   This document has been written to address errata in a previous
>   version of this specification.
> END
> 
> But, actually, I think you are missing the main purpose which is to
> advance the spec to full standard.

As noted above I think the key was fixing errata.  The standard thing came after that - but that may be me and Luca mis-remembering the history.

> On reflection, I think that this paragraph probably served well in the
> draft as it was being processed, but can be removed now. The equivalent 
> text obviously needs to be in the shepherd write-up.

ok - that makes sense.

> [ditto the paragraph in the introduction]

ditto.

> ---
> 
> Thank you for including Section 1. It's important and helpful.
> 
> Three tiny points:
> 
> Second para should probably s/However/Additionally/

will fix.

> The RFC Editor requires that section 1 is the Introduction. A simple
> solution is to swap sections 1 and 2, or to move the current section 2
> to be the new section 1 and the current section 1 to be section 1.1.

again - that makes sense.

> The text says "A note was added to clarify that the C-bit is part of 
> the FEC." I think you should s/was/has been/ and you could also usefully
> give a little hint as to where the note was added.

ok.

> ---
> 
> Shouldn't you mention the inclusion of text referencing 7358? This is
> clearly a change to the original text. I wonder, however, whether what
> really want to do is take that part of 7358 that updated 4447 and simply
> write it here so that this spec has no need of that reference.

presumably better to reference 7358 so we don’t duplicate text?

> Either way, you also need to take care about the stability requirement 
> for advancement.

you mean standards track vs informational etc.?

---
> 
> In 6.2.2.1
> please note that IANA has "PW Interface Parameters TLV" not "Interface
> Parameters TLV".
> 
> The is a good chance to make this consistent.

ok

> ---
> 
> In 6.2.2.2 and the rest of the document, please note that the IANA has
> "PW Group ID TLV" not "PW Grouping ID TLV".
> 
> The is a good chance to make this consistent.

ok

> ---
> 
> 6.3.2 has a figure which claims to include a "PWId FEC TLV" or a
> "Generalized ID FEC TLV". However, 6.1 and 6.2 describe these as
> "elements" not TLVs and they show up in the Forwarding Equivalence Class
> (FEC) Type Name Space.
> 
> I think you can clarify 6.3.2 by explaining that what is included here
> is "a FEC TLV containing either a PWId FEC element or a Generalized FEC
> element.
> 
> Then, just after the figure you have "The PW FEC TLV" but it is just a
> "FEC TLV”

ok

> ---
> 
> In 7.3 you have "re-provisioned". I wonder whether you mean
> "re-configured". "Provisioning" has a context initial set-up, so re-
> provisioning suggests (to me?) re-initialization.

ok

> ---
> 
> In the first para of 7.3 you have "PW C-bit negotiation procedure" and
> "Control-Word negotiation procedures".
> 
> Could you decide on a single name, and on whether it is singular or
> plural.
> 

ok

> ---
> 
> 7.3
> OLD
>        -i. If local PE has previously sent a Label Mapping message, it
>            MUST send a Label Withdraw message to remote PE and wait
> NEW
>        -i. If the local PE has previously sent a Label Mapping message, it
>            MUST send a Label Withdraw message to the remote PE and wait
> END

ok

> ---
> 
> 7.3
> OLD
>       -ii. the local PE MUST send a label release message to the remote
> NEW
>       -ii. The local PE MUST send a Label Release message to the remote
> END

ok

> ---
> 
> 7.3
> s/negotaiation/negotiation/
> s/renegotation/renegotiation/

ok

> ---
> 
> 7.3
> 
>   The above C-bit renegotiation process SHOULD NOT be interrupted until
>   it is completed, or unpredictable results might occur.
> 
> This is a bit odd. Normally the "or" that follows a "SHOULD" or "SHOULD
> NOT" explains the conditions under which you might want to vary the 
> "SHOULD". 
> 
> But I'm struggling: interrupted by whom and by doing what?

I’ll have to defer to Luca here.

> 
> --- 
> 
> Some of the formatting in the references seems to have been hit with a
> global change of /. /.  / You might want to polish.

will do

> ---
> 
> The latest version of G.707 is dated January 2007. Is there any reason
> to not update the reference?

probably just that we never revisited it.

> ---
> 
> Have a look at Section 8 of RFC 5036 for an example of a nice way to
> handle "legacy authors" and credits for past work.
> 
> In any case, the RFC Editor will require that Section 15 is renamed 
> "Contributors”.

ok

> ---
> 
> There are two trivial nits from idnits.
> 

will take a look

Giles

---

From: Stewart Bryant <[email-masked]>
Date: Thu, 5 May 2016 15:12:13 +0100

Please see SB>

> it is marked that way.  but it’s only when it goes to RFC that that gets into the text?

SB> No, Giles, Adrian is correct. The Top Left corner of the front page 
should have a list of RFCs being obsoleted.

SB> Thus after "Intended status: Internet Standard" there should be a 
line saying
SB> Obsoletes: RFC4447, RFC6723

SB> We also need replace the last para in the Abstract with something like.

SB> This document has been published to address RFC4447 errata. It replaces
SB> RFC4447 and incorporates the correction published in RFC6723. In doing
SB> so it obsoletes RFC4447 and RFC6723.

SB> At the end of Section 1, you need something like:

SB> This document replaces and thus obsoletes RFC4447 and RFC6723.

>> existing RFCs?" seems to need a much clearer answer!]
SB> I will update the Shepherds report when the new version of 
RFC4447bis is uploaded

> RFC4447-bis is being done because there were too many errata on 4447.   There won’t as many on the others.  I think the promotion to Internet Standard happened as part of that?

SB> Promotion to standard seemed the right thing given the wide 
deployment of this signalling scheme.

SB> If we all feel that we need to jump through too many hoops, we could 
just leave it as PS, although all of the issues we are discussing here 
will need to be addressed either way.

> I think maybe we just need a note asking IANA to remove this section once the RFC is published, and to update all the registries with the new number of this RFC?

SB> I think the point that Adrian is making is that you should strike 
"in general".

SB> All of the IANA entries that point to RFC4447 should be replaced.

>> [NB: The Shepherd write-up seems to report all this wrongly at Q17]
SB> I have corrected the Shepherd's writeup.

> can we put URLs into references?  And can they be that long? ;)

SB> Yes, and Yes

> As noted above I think the key was fixing errata.  The standard thing came after that - but that may be me and Luca mis-remembering the history.

SB> I am fairly sure that the Chairs suggested moving to Full Std. As I 
said earlier if it is too many hoops perhaps we should just publish as 
PS, although that says something about the IETF process given how widely 
this is implemented.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 5 May 2016 18:20:42 +0100

Stewart beat me to the draw on a couple of points. I agree with him, so I've cut down to other issues.

> > I wait with bated breath ;)

Indeed!

> > RFC4447-bis is being done because there were too many errata on 4447.   There
> > won’t as many on the others.  I think the promotion to Internet Standard
> > happened as part of that?
> 

So I'm not demanding anything, just asking the question that your AD might also ask.

I think promotion to standard is a fine idea for this document. I also appreciate the desire to not ingest more work. However, I think some (all?) of the other documents might advance with just a last call.

Anyway. Whatever.

> > the issue is that 4447 failed to cover a corner-case that was documented in
> > 6723.   So 6723 could be seen as a super-erratum on 4447.  4447bis merges it in as
> > a single document.

Right. And Stewart's fixes for "obsoletes..." handle this.

> > that were pre the 4447 standard).

OK. Do we need that? Still?

> > I’m not sure we want to make big text changes at this stage for marginal

It isn't a big technical change. It's just words.

But if you are concerned then this needs to be a negotiation with the AD "at this stage".

Personally, I like specs that are easy to read :-)

> > again I’m not sure I’d want to make major changes to the text if we can avoid it.

Ditto.

> > I think maybe we just need a note asking IANA to remove this section once the
> > RFC is published, and to update all the registries with the new number of this
> > RFC?
> 

Yeah, the section is needed and so are the instructions. But "in general" is unnecessary.

> > ok - we’ll rely on IANA to do this :)

How so? IANA *do* supply a statement of their actions to the RFC Editor, but they do not "in general" edit the text.

> > The AD asked us to put this in to provide evidence for moving to Internet
> > Standard.  Happy to remove it again of course if the AD requests :)

OK. That's between you and the IESG.

> > understood.  We were just trying to show that PW was widely implemented.

Fine, you certainly achieved on your intention.

> >> http://www.eantc.de/fileadmin/eantc/downloads/events/2007-
> >> 2010/MPLSEWC09/EANTC-MPLSEWC2009-WhitePaper-v1.0.pdf
> > I put:  "The pseudowire technology was first deployed in 2001 and has been
> widely deployed by many carriers.”  I’m not sure what more we can do.   Provide
> lists of carriers offering services based on pseudowires?  That’d be *very*
> temporarlly unstable ;)

That's why implementation surveys are done the way they are.

And, again, we're looking at 4447 implementation and deployment, not at PWs in general.

For what it is worth, I don't doubt that this is widely implemented and deployed, but I'm not on the IESG and it is them who you have to convince.

> > so they’re all addressed as noted above.  And we can say “mostly editorial”?

Actually, you can leave this. They were addressed in an editorial way.

> > I’m really not sure how we prove that.

It is the implementation report's job to collect this information.
Maybe the IESG don't care anymore and will take your word for it.

> > right - so as far as we know all the features are in use by multiple vendors.  I’ve
> asked around inside Cisco to check our implementations, but I’m very happy for
> someone else to check with our competitors.

Well, that's OK then. Just checking.

> >> or to the Internet-Drafts that resulted in RFC 4447 and RFC 6723.”).

Cheers,
Adrian

---

From: Luca Martini <[email-masked]>
Date: Thu, 5 May 2016 12:00:56 -0600

Giles/Adrian,
I added more comments below: LM>

On 05/05/16 08:12, Stewart Bryant wrote:
>>> I have been selected as the Routing Directorate reviewer for this
>>> draft. The Routing Directorate seeks to review all routing or
>>> routing-related drafts as they pass through IETF last call and IESG
>>> review. The purpose of the review is to provide assistance to the
>>> Routing ADs. For more information about the Routing Directorate,
>>> please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir
>>>
>>> Although these comments are primarily for the use of the Routing
>>> ADs, it would be helpful if you could consider them as the draft
>>> advances, and strive to resolve them through discussion or by
>>> updating the draft.
>>>
>>> Thanks,
>>> Adrian
>>>
>>> ===
>>>
>>> I'm OK to see 4447 being advanced to full standard, although I'm
>>> also a little surprised that there was energy to do it.
>>>
>>> The work is largely mechanical. My comments are a mix of minor
>>> process concerns (that your AD should be able to resolve), minor
>>> text clarifications, and nits.
>>>
>>> It's been a while since I was concerned with LDP, but I have no
>>> reason to doubt the integrity of this document.
>>>
>>> = Major Issues =
>>>
>>> No major issues found.
>>>
>>> = Minor Issues =
>>>
> SB> No, Giles, Adrian is correct. The Top Left corner of the front
> page should have a list of RFCs being obsoleted.
>
LM> Yes , there is a bug in the script that generates the text, I have
never fixed it since there is not enough incentive to ;-)
Let's just remember to manually edit the text before submission.
>> RFC4447-bis is being done because there were too many errata on
>> 4447.   There won’t as many on the others.  I think the promotion
>> to Internet Standard happened as part of that?
>
> SB> If we all feel that we need to jump through too many hoops, we
> could just leave it as PS, although all of the issues we are
> discussing here will need to be addressed either way.
>
>>  
>>> ---
>>>
>> the issue is that 4447 failed to cover a corner-case that was
>> documented in 6723.   So 6723 could be seen as a super-erratum on
>> 4447.  4447bis merges it in as a single document.
>>
>>> ---
>>>
>> it means for interop with extremely old implementations
>> (implementations that were pre the 4447 standard).
>>
LM> Andrian, we cannot change the specification in this stage. So the
word "legacy" above needs to stay to discourage future implementation
from being lazy and not implementing section 6.3.2.
So if we work in the original meaning I'm fine with your clarified text.
We are just shaming implementations into compliance ;-)

>> again I’m not sure I’d want to make major changes to the text if
LM> On this I agree with Adrian. It's a nit , but he is correct , we can
make this change. Clearly the message type is not 0 , and that was a
mistake in the original text.

>> I think maybe we just need a note asking IANA to remove this section
>> once the RFC is published, and to update all the registries with the
>> new number of this RFC?
>
LM> I agree , but doen't IANA do this automatically when you obsolete an
RFC ?
Let's just get IANA to do the right thing.

>> The AD asked us to put this in to provide evidence for moving to
>> Internet Standard.  Happy to remove it again of course if the AD
>> requests :)
>>
LM> As Giles pointed out , THe AD requested it. And the have an RFC with
an interop report of sorts, just focused on the C-Bit.

>> I put:  "The pseudowire technology was first deployed in 2001 and has
>> been widely deployed by many carriers.”  I’m not sure what more
>> we can do.   Provide lists of carriers offering services based on
>> pseudowires?  That’d be *very* temporarlly unstable ;)
>>
>> right - so as far as we know all the features are in use by multiple
>> vendors.  I’ve asked around inside Cisco to check our
>> implementations, but I’m very happy for someone else to check with
>> our competitors.
>>
>> As noted above I think the key was fixing errata.  The standard thing
>> came after that - but that may be me and Luca mis-remembering the
>> history.
>
> SB> I am fairly sure that the Chairs suggested moving to Full Std. As
> I said earlier if it is too many hoops perhaps we should just publish
> as PS, although that says something about the IETF process given how
> widely this is implemented.
>
>>
LM> This was in reference that in the original spec we had no "reset"
button for this negotiation. So i wanted to make sure that if someone
changed the provisioning in the middle of the negotiation, the system
would finish the state machine, then initiate a new procedure.  It's
just attempting to protect against very bad coding.  The reason it is a
should is that if we have a label withdraw in the middle of it it's ok ,
as all state is erased at that point.

---

From: "BRUNGARD, DEBORAH A" <[email-masked]>
Date: Thu, 5 May 2016 19:29:24 +0000

I answered this first question on 10/26/2015 for Stewart (cc'd authors and chairs). (my memory is still good:-))

It's still the same answer, but considering this document's revision time, maybe it will change. I didn't realize all of you were holding your breath for the answer:-)

Answer: We need to do "downward references". I had sent links in my previous email to recent IS documents as examples, e.g.:
https://www.rfc-editor.org/rfc/rfc7680.txt
(has normative references including PS, BCP)

How to do:
https://tools.ietf.org/rfc/rfc4897.txt

-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Thursday, May 05, 2016 1:21 PM
To: 'Stewart Bryant' <[email-masked]>; 'Giles Heron (giheron)' <[email-masked]>; 'Luca Martini (lmartini)' <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: RE: Routing Directorate review of draft-ietf-pals-rfc4447bis

> > I wait with bated breath ;)

Indeed!
<snip>