Re: [Pce] PCE WG Last Call on draft-ietf-pce-iro-update-01

[Dhruv Dhody <[e-mail]>]

Hi Adrian,

Thanks for your review, please see the attached working-copy/diff.  

> -----Original Message-----
> From: Pce [mailto:[e-mail]] On Behalf Of Adrian Farrel
> Sent: 05 May 2015 22:14
> To: [e-mail]
> Subject: Re: [Pce] PCE WG Last Call on draft-ietf-pce-iro-update-01
> 
> Hi,
> 
> No objections to this document from me, and thanks to the author for the
> diligence with which he checked the impact of this change. We can't see from
> the outside whether enough of the "real implementers" responded, but they had
> their chance and this last call is their last chance :-)
> 
> ---
> 
> I think it would be helpful if the "update" to RFC 5440 was more anchored
> into that document.
> 
> So...
> 
> The update is to section 7.12, yes?
> The text in the last paragraph of your section 2 is to be considered part of
> the spec, yes?
> The text is intended to replace the last line of 5440/7.12 that currently
> says
>    The L bit of such sub-object has no meaning within an IRO.
> 
> I also think there is a bit of an over-use of "MUST" in...
>    The content of an IRO object MUST be an ordered list of subobjects
>    representing a series of abstract nodes.
> Using "is" would be more appropriate. You could go "MUST be interpreted as",
> but that also sounds excessive use of language.
> 

Okay, updated accordingly. Section 2 now says - 

   This document thus updates [RFC5440] regarding the IRO specification
   and is intended to replace the last line in section 7.12 of
   [RFC5440], that states -

       "The L bit of such sub-object has no meaning within an IRO."

   As per the update in this document, the L Bit of IRO sub-object is
   set based on the loose or strict property of the sub-object, which is
   set if the sub-object represents a loose hop.  If the bit is not set,
   the sub-object represents a strict hop.  The interpretation of Loose
   bit (L bit) is as per section 4.3.3.1 of [RFC3209].

   Also, as per the update in this document, the content of IRO is an
   ordered list of sub-objects representing a series of abstract nodes.
   An abstract node could just be a simple abstract node comprising one
   node or a group of nodes for example an AS (comprising of multiple
   hops within the AS) (refer section 4.3.2 of [RFC3209]).

> ---
> 
> In the Introduction you say
>    During discussion of [I-D.ietf-pce-pcep-domain-sequence] it was
>    proposed to have a new IRO type with ordered nature, as well as
>    handling of Loose bit (L bit).
> 
> This is completely true and indisputable. But appearing like this it raises
> more questions than it answers. Either delete the paragraph or add some
> resolution such as "however, with the update to RFC 5440 described in this
> document, no new IRO type is needed."
> 

Okay, added the resolution, and moved the paragraph.

> ---
> 
> Section 2 has
> 
>    A survey of the existing and planned implementations was conducted in
>    order to discover the current state of affairs amongst
>    implementations.  [I-D.dhody-pce-iro-survey] describe the
>    questionnaire, results and presents some conclusions and proposed
>    action items.  More details in Appendix A.
> 
> Having read App A I don't think it adds any more details to what is in the
> Intro and in this paragraph.
> You have the reference to the survey i-D (which will stay in the archives for
> ever), so I suggest to delete the appendix and the pointer to it.
> 

Ack. 

> ---
> 
> It looks to me that RFC 3209 is a normative reference since I must look there
> to find out how to interpret the L bit.
> 

Yes! Done! 

> Cheers,
> Adrian
> 

Thank you for the comments. 

Regards,
Dhruv

> 
> > This message initiates a 2-week WG last call on
> > draft-ietf-pce-iro-update-01. Please send your comments to the PCE
> > mailing list by Tuesday May 19.
> >
> > Thanks,
> >
> > JP & Julien
> 
> _______________________________________________
> Pce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pce