Subject: Re: [v6ops] draft-bao-v6ops-rfc6145bis WGLC

From: <[email-masked]>
Date: Tue, 1 Dec 2015 14:11:15 +0100

Hello,

some comments:

- draft-anderson-v6ops-siit-eam is now on version 03, and in the RFC Editor queue - should RFC6145bis waint until the EAM RFC is published to get the references right?

- A.1 step 1 suggests that the IPv6 host must perform the formation of the IPv6 destination address from the IPv4 address of the peer on its own, knowing the address mapping algorithm. Should it be mentioned here that the mapping could have been done externally, e.g. by a AAAA DNS entry or inband signalling, so that the mapping algorithm does not need to be known on the v6 host (same applies for A.2)?

- 3.1: Translation of the Source and Destination Address: While the algorithms are stated, it is unclear to me what the translator should do if it finds a translation only for the source address, but not for the destination address, and vice versa? Section 5 says that RFC6052 is the default mapping, but this is a "SHOULD" so we could end up in a situation where not both source and destination address can be translated at the same time.

Holger

-----Ursprüngliche Nachricht-----
Von: v6ops [mailto:[email-masked]] Im Auftrag von [email-masked]
Gesendet: Sonntag, 29. November 2015 20:00
An: [email-masked]
Betreff: [v6ops] draft-bao-v6ops-rfc6145bis WGLC

This is to initiate a two week working group last call of http://tools.ietf.org/html/draft-bao-v6ops-rfc6145bis.  
Please read it now. If you find nits (spelling errors, minor suggested wording changes, etc), comment to the authors; if you find greater issues, such as disagreeing with a statement or finding additional issues that need to be addressed, please post your comments to the list.

We are looking specifically for comments on the importance of the document as well as its content. If you have read the document and believe it to be of operational utility, that is also an important comment to make.

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fernando Gont <[email-masked]>
Date: Tue, 1 Dec 2015 12:27:06 -0300

Hi, Holger,

One quick answer:

> - draft-anderson-v6ops-siit-eam is now on version 03, and in the RFC Editor queue - should RFC6145bis waint until the EAM RFC is published to get the references right?

It will happen that way, anyway. We still ahve to go through IETF LC and
IESG review... so draft-anderson-v6ops-siit-eam will be published first,
and by the time the RFC Editor works on the I-D, all the outdated
references will be updated to the current ones -- including the one you
point out.

Thanks!

Cheers,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: David Farmer <[email-masked]>
Date: Tue, 1 Dec 2015 16:58:20 -0600

I echo the three nits below from Brian that don't seem to have been 
addressed.

I'll add the acknowledgements section alludes to the changes by thanking 
people for some of them, while that it good, its not sufficient. 
Without a summary of the changes it was difficult to review the document 
properly.

Thanks.

On 7/4/15 15:23 , Brian E Carpenter wrote:
> There are nits:
>
>> This document updates RFC 6145.
>
> Surely that should be "obsoletes" (if not, it isn't a "bis" document).
>
> IMHO, unless you have explicit permission from the author of RFC 2765,
> you still need the <rfc ipr="pre5378Trust200902"> boilerplate.
>
> A short "Changes from RFC6145" appendix would be useful.
>
> Regards
>    Brian

On 11/29/15 13:00 , [email-masked] wrote:
> This is to initiate a two week working group last call of
> http://tools.ietf.org/html/draft-bao-v6ops-rfc6145bis.
> Please read it now. If you find nits (spelling errors, minor suggested
> wording changes, etc), comment to the authors; if you find greater
> issues, such as disagreeing with a statement or finding additional
> issues that need to be addressed, please post your comments to the
> list.
>
> We are looking specifically for comments on the importance of the
> document as well as its content. If you have read the document and
> believe it to be of operational utility, that is also an important
> comment to make.
>

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: <[email-masked]>
Date: Wed, 2 Dec 2015 15:57:05 +0000

Hi all,

draft-bao-v6ops-rfc6145bis incudes an "Obsoletes" header but the abstract text indicates the draft updates RFC 6145.  

Given the list of documents that reference RFC6145 (see the list in https://datatracker.ietf.org/doc/rfc6145/referencedby/) wouldn't just be OK if this document focuses on UPDATES to RFC6145 rather than obsoleting it.

Cheers,
Med

> wording changes, etc), comment to the authors; if you find greater issues,
> such as disagreeing with a statement or finding additional issues that
> need to be addressed, please post your comments to the list.
> 
> We are looking specifically for comments on the importance of the document
> as well as its content. If you have read the document and believe it to be
> of operational utility, that is also an important comment to make.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 3 Dec 2015 13:09:37 +1300

> Given the list of documents that reference RFC6145 (see the list in https://datatracker.ietf.org/doc/rfc6145/referencedby/) wouldn't just be OK if this document focuses on UPDATES to RFC6145 rather…

But if it's a bis document, by definition it obsoletes the original.
If there are any useful parts of 6145 that are missing from 6145bis,
that's a bug.

Of course we often have references to obsolete documents. That's a general
problem with RFCs. See https://tools.ietf.org/html/draft-klensin-isdbis-00.

   Brian

---

From: <[email-masked]>
Date: Thu, 3 Dec 2015 06:35:53 +0000

Hi Brian, 

My comment is that I'm not sure having a bis document is the appropriate way to proceed. I do think having a brief and concise document with updates to RFC6145 would be sufficient. 

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : v6ops [mailto:[email-masked]] De la part de Brian E Carpenter
> Envoyé : jeudi 3 décembre 2015 01:10
> À : [email-masked]
> Objet : Re: [v6ops] draft-bao-v6ops-rfc6145bis WGLC
> 
> > draft-bao-v6ops-rfc6145bis incudes an "Obsoletes" header but the
> abstract text indicates the draft updates RFC 6145.
> >
> > Given the list of documents that reference RFC6145 (see the list in
> https://datatracker.ietf.org/doc/rfc6145/referencedby/) wouldn't just be
> OK if this document focuses on UPDATES to RFC6145 rather than obsoleting
> it.
> 
> issues,
> document

---

From: Fernando Gont <[email-masked]>
Date: Thu, 3 Dec 2015 21:14:39 -0300

On 12/02/2015 12:57 PM, [email-masked] wrote:
> https://datatracker.ietf.org/doc/rfc6145/referencedby/) wouldn't just
> be OK if this document focuses on UPDATES to RFC6145 rather than
> obsoleting it.

Not really. Even with just the bit about deprecation of atomic
framgents, you get a rather long "diff" that spans the whole document.
The diff becomes hard to read, and 6145 also becomes had to read, since
you know it's patched all over the place.

There's nothing wrong with obsoleting RFC6145. RFC6145bis takes its
place... so it's not that "now all out of the sudden the RFC they were
referencing is gone".

I think the current path is the right one.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Fred Baker (fred)" <[email-masked]>
Date: Tue, 8 Dec 2015 19:22:02 +0000

> On Dec 1, 2015, at 5:11 AM, [email-masked] wrote:
> 
> Hello,
> 
> some comments:
> 

The RFC Editor generally changes the ID reference to an RFC reference for us. I don't see the need for this.

---

From: "Liushucheng (Will)" <[email-masked]>
Date: Wed, 9 Dec 2015 07:30:29 +0000

Hi folks,

I support the publication of this document as an RFC. However, I agree with the posted comments that this document should be clearer regarding the changes from RFC6145. I suggest a new section or appendix be added that makes such changes explicit.

Since I'm involved in one of the I-Ds that led to the updates in this document, I would like to suggest part of the contents of such new section/appendix like:

 B. Changes since RFC6145

   o Reliance on IPv6 atomic fragments has been removed, as a result
     of the analysis in [draft-ietf-6man-deprecate-atomfrag-generation].
     We note that support of IPv6 atomic fragments is currently in the
     process of being removed from the revised core IPv6 specification
     [draft-ietf-6man-rfc2460bis].

Similar text should be added regarding the other documents leading to this update.

Regards,
Will (Shucheng LIU)

> -----Original Message-----
> From: v6ops [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Monday, November 30, 2015 3:00 AM
> To: [email-masked]
> Subject: [v6ops] draft-bao-v6ops-rfc6145bis WGLC
> 
> Please read it now. If you find nits (spelling errors, minor suggested wording
> changes, etc), comment to the authors; if you find greater issues, such as
> disagreeing with a statement or finding additional issues that need to be
> addressed, please post your comments to the list.
> 
> as well as its content. If you have read the document and believe it to be of
> operational utility, that is also an important comment to make.
>