Re: 6MAN WG Last Call: <draft-ietf-6man-node-req-bis-07.txt>

[Pekka Savola <[e-mail]>]

On Thu, 10 Mar 2011, Thomas Narten wrote:
>> Some requirement levels have also changed, and explicit support from
>> WG would be good on these.  With an updated RFC4294 changelog, rough
>> consensus on the result could be evaluated.
>
> OK. But to be clear, the changes in this document have been discussed
> on the list and IMO do have consensus. I.e., they are not "surprises".

Yes, I don't doubt they've been mentioned, but given the long time 
cycle and that a lot of participants do not have time to read all 
the mails very closely, strong consensus can be best built by 
iteration. (But it can also lead to iteration cycles and hashing the 
same issues over and over again, of course)

>> The document should be IETF last called.
>
> No objection.

Wrt. to Bob's comment, I was just pointing out that Informational 
documents do not (by IETF procedures) require an IETF Last Call. It's 
good that 6MAN documents have set a higher bar :-)

>> WG should explicitly request feedback from at least IPSECME WG.
>
> IPsecME has seen and reviewed text. Indeed, some IPsecME members
> helped with getting the text right. I also presented the text at the
> saag meeting in Maastricht

Great to hear, maybe this is a non-issue then!

>> I think this document should also discuss APIs we have defined and that
>> relate to the protocols described in the document.  A separate section
>> should be added on this.
>
> I added a section on APIs. I made them all FYIs. I agree with the
> comments others have made on the list that we can't mandate them.

Works for me.

>> S 5.8.3 has watered down the privacy addresses text:
>
>>     In such situations, RFC4941 SHOULD be implemented.  In other cases,
>>     such as with dedicated servers in a data center, RFC4941 provides
>>     limited or no benefit.
>
>> .. this is not acceptable.  Per previous RFC, we should say:
>
>>     RFC4941 SHOULD be supported.
>
> I strongly disagree, and there was a thread about this. I have seen
> cases where people just assume that 4941 should be supported by all
> nodes, including servers (not clients) in data centers. There is no
> need to implement 4941 on server-only systems.
>
> Please review the thread at
> http://www.ietf.org/mail-archive/web/ipv6/current/msg10468.html and if
> you have further comments, speak up. But it was an explicit goal to
> not just say "SHOULD" with not context/direction, as RFC 4294 does.

I should have articulated my objection more clearly. The issue stems 
from the word "implemented".  I totally agree that it's a bad idea to 
turn on 4941 on server nodes.  But because it's usually difficult to 
distinguish purely client and server implementations, in most cases 
4941 should be implemented -- the big question is really whether to 
turn it on or off.

>
>> In S 5.9,
>>     A reference should be added (MAY support) to RFC 5790,
>> "Lightweight Internet Group Management Protocol Version 3 (IGMPv3) and
>> Multicast Listener Discovery Version 2 (MLDv2) Protocols"
>
> Actually, I may need some help with this.
>
> If 5790 is enough, and omits functionality that most nodes don't need,
> we should recommend its usage.
>
> We should provide clear guidance on when it makes sense to recommend
> one over the other.

Hitoshi Aseada (author) made some suggestions on this on the list on 
Feb 21-22.  IMHO, 5790 seems enough and only omits functionality that 
the most nodes don't need (but I also don't see a pressing need for 
existing implementations to take out these bits).

....

A few editorial bugs in the latest version:

- the added text on more-specific routes (S 5.3) mistakenly points to
   rfc5942.

- running " in the added rfc4941 text in S 5.9.3

- there's some overlap in the changelog section, at least rfc5952 and
   rfc5722 are mentioned twice. (strange to see both numbered and
   non-numbered entries there as well.)


-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings