RE: Working Group Last Call on draft-ietf-ccamp-gmpls-addressing-06.txt

["MEURIC Julien RD-CORE-LAN" <[e-mail]>]

Hi all.

Just a few comments about the ID.

In the abstract and the introduction, the phrase "facilitate better interworking" reads weird to me. I'm not a native English speaker, but wouldn't "facilitate interworking" be more appropriate?

About the IGP terminology, in OSPF and IS-IS RFCs, "OSPF-TE" and "IS-IS-TE" terms are reserved for MPLS-TE extensions (RFC 3630 and 3784) while GMPLS ones (RFC 4203 and 4205) are rather named "GMPLS OSPF" and "GMPLS IS-IS". I believe the ID should follow this terminology more closely.

In section 5.1.1:
   "An unnumbered TE
   link end network-wide identifier is comprised of a TE Router ID
   associated with the link local end, followed by the link local
   identifier"
-> The intent on (TE Router ID, link local ID) is clear to anyone familiar with the context, but I also feel -- due to my mother tongue? -- that this might also be misread as (TE Router ID, link local end, link local ID), which does not make any sense. However, considering this is a clarification document, maybe replacing "associated with" by "corresponding to" or just recalling it's a pair would do the trick.

In section 6.1.2:
   "If the interface was intended to be used as an outgoing
   interface, the path will be broken an may be impossible to resolve."
-> s/an/and/
-> "The path will be broken" looks like a postulate and needs a clarification.

   "This a loose hop that identifies an interface should always identify
   the incoming TE link in the data plane."
-> Something's missing or "This" should be removed.


Regards,

Julien


-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Adrian Farrel

Hi,

After some delay, this I-D has been updated as requested by the working 
group to move it on to the Informational track.

As well as the obvious change to the front page, all of the 2119 language 
has been removed and references have been inserted to the definitive 
material in other RFCs.

The Abstract now clearly states "This document does not define new 
procedures of processes."

And the Introduction contains...

   This document does not define new procedures of processes and the
   protocol specifications listed above should be treated as definitive.

I think this should be compatible with the working group's wishes, and I 
think that the I-D is now in relatively good shape to be taken to the IESG, 
so...

This begins a two week working group last call. Please send your comments to 
the mailing list.

The last call will end at 6pm GMT on Sunday 6th May 2007.

Thanks,
Adrian