[rrg] Fwd: [irsg] IRSG Poll Request: ILNP document suite

[Tony Li <[e-mail]>]

Hi Ran & Saleem,

We've started soliciting other IRSG members to review and comment on the current documents.  Thomas Schmidt has been very kind to very quickly review the documents and has provided the following comments.

AFAIK, it's perfectly kosher to have IANA requests in IRTF experimental track RFCs.

Could you please respond to Thomas' other comments?

Thanks,
Tony


Begin forwarded message:

> From: "Thomas C. Schmidt" <[e-mail]>
> Subject: Re: [irsg] IRSG Poll Request: ILNP document suite
> Date: April 6, 2012 3:15:48 PM PDT
> To: Tony Li <[e-mail]>
> Cc: Internet Research Steering Group <[e-mail]>
> 
> Dear Tony,
> 
> having thoroughly reviewed earlier versions of the documents, I promised to react quickly on the update - and here I am.
> 
> The documents have undergone a significant reorganization and rewrite (including the number and dedication of the documents) and are much clearer and more precise now. The ~180 pages are still very verbose and partly redundant, but this should be the freedom of authors ;).
> 
> There are several requests to the IANA registry on the proposed IRTF experimental track, and I'm not sure about the legitimacy of this.
> 
> The technical issues I head earlier seem cleared except for the multicast addressing case.
> 
>  As raised in my previous review, there is some misleading text w.r.t. multicast addresses and compatibility to IPv6. The authors have now specified to use the MAC-Layer group bit in the EUI-64 format for multicast address indication. I don't object doing so, but such addresses will not be compatible to the IPv6 multicast address format.
> 
> This is in contradiction to repeated statements about full compatibility to IPv6:
> 
> Two striking examples (out of very many):
> 
> draft-irtf-rrg-ilnp-arch-01, Sect. 8:
> 
> "ILNPv6 is fully backwards compatible with existing IPv6. No
>   router software or silicon changes are necessary to support the
>   proposed enhancements."
> 
> draft-irtf-rrg-ilnp-eng, Sect. 9:
> 
> " ILNP is designed to be deployed on existing infrastructure. No
>   new infrastructure is required to run ILNP as it will be
>   implemented as a software upgrade impacting only end-to-end
>   protocols. Existing routing protocols can be re-used: no new
>   routing protocols are required. "
> 
> For the sake of precision, I would suggest to explicitly confine these compatibility statements to unicast.
> 
> Aside from this, I vote 'Ready to publish'.
> 
> There are a number of minor nits:
> 
> * RFC 3775 -> RFC 6275
> * References [8+8], [GSE], [IEEE-EUI], [SRC 84] are incomplete in draft-irtf-rrg-ilnp-arch-01
> * Throughout the documents, hyperreferences tend to point incorrectly
> * Some number of typos and editorial stuff the RFC-Editor will most likely fix.
> 
> 
> Thanks,
> 
> Thomas
> 
> On 04.04.2012 09:24, Tony Li wrote:
>> 
>> Dear IRSG Members,
>> 
>> The IRSG review of the ILNP document set was completed long ago, but our RFC process requires that at least two other IRSG members vote that the documents are "ready to publish".  We have one vote already and have been seeking another vote for quite some time.
>> 
>> In order to meet with IRSG approval, the document authors have undertaken a significant rewrite of the document set.  The intent of this rewrite has been to further reorganize, rationalize, fill in missing detail and generally clarify the architecture.  Because of the degree of change, the entire document set has been again reviewed by the RRG, and, after further clarifications, it is the consensus of the RG that these documents are ready to proceed.
>> 
>> Therefore, I am looking for a volunteer to review the document set and provide a poll response.  Per the RFC process, the possible poll responses are:
>> 
>>   o  'Ready to publish' -- requires a thorough read and reasonably
>>       detailed review
>> 
>>   o  'Not ready to publish' -- requires a thorough read, reasonably
>>      detailed review, and actionable comments.
>> 
>>   o  'No objection' -- I don't object if this document goes forward;
>>      I've read the document (perhaps quickly); I have some small
>>      comments which are not show stoppers; I don't have great
>>      expertise in the area.
>> 
>>   o  'Request more time to review' -- a commitment to provide a
>>      thorough review in a specified period of time.
>> 
>> The documents are:
>> http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-adv-01.txt
>> http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-arch-01.txt
>> http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-arp-01.txt
>> http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-dns-01.txt
>> http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-eng-01.txt
>> http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-icmpv4-01.txt
>> http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-icmpv6-01.txt
>> http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-noncev6-01.txt
>> http://www.ietf.org/internet-drafts/draft-irtf-rrg-ilnp-v4opts-01.txt
>> 
>> If you are willing to volunteer to help with this process, please contact me.
>> 
>> While the overall set may seem daunting at first, the total page count is 182, so this is a tractable amount, especially after the requisite boilerplate repetition is discounted.
>> 
>> Thanks,
>> Tony
>> 
> 
> -- 
> 
> Prof. Dr. Thomas C. Schmidt
> ° Hamburg University of Applied Sciences                   Berliner Tor 7 °
> ° Dept. Informatik, Internet Technologies Group    20099 Hamburg, Germany °
> ° http://www.haw-hamburg.de/inet                   Fon: [phone] °
> ° http://www.informatik.haw-hamburg.de/~schmidt    Fax: [phone] °