Hi,
> On 6 Feb 2018, at 10:13, [email protected] wrote:
>
> Re-,
>
> Please see inline.
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Tim Chown [mailto:[email protected]]
>> Envoyé : mardi 6 février 2018 10:38
>> À : BOUCADAIR Mohamed IMT/OLN
>> Cc : [email protected]; [email protected];
>> [email protected]
>> Objet : Re: Opsdir early review of draft-ietf-opsawg-nat-yang-10
>>
>> Hi Med,
>>
>>> On 6 Feb 2018, at 09:02, [email protected] wrote:
>>>
>>> Hi Tim,
>>>
>>> Thank you for the review.
>>>
>>> Please see inline.
>>>
>>> Cheers,
>>> Med
>>>
>>>> -----Message d'origine-----
>>>> De : Tim Chown [mailto:[email protected]]
>>>> Envoyé : lundi 5 février 2018 20:07
>>>> À : [email protected]
>>>> Cc : [email protected]; [email protected]
>>>> Objet : Opsdir early review of draft-ietf-opsawg-nat-yang-10
>>>>
>>>> Reviewer: Tim Chown
>>>> Review result: Has Nits
>>>>
>>>> I have reviewed this document as part of the Operational directorate's
>>>> ongoing
>>>> effort to review all IETF documents being processed by the IESG. These
>>>> comments were written with the intent of improving the operational aspects
>> of
>>>> the IETF drafts. Comments that are not addressed in last call may be
>> included
>>>> in AD reviews during the IESG review. Document editors and WG chairs
>> should
>>>> treat these comments just like any other last call comments.
>>>>
>>>> This document defines a YANG model for a wide variety of NAT functions,
>>>> including NAT44, NAT64, CLAT, SIIT and NPT66.
>>>>
>>>> The document is generally well written, and structured appropriately.
>> There
>>>> are some very minor grammatical errors. Appropriate documentation prefixes
>>>> are
>>>> used in the Appendix of examples.
>>>>
>>>> I believe the document is Ready for publication, with Nits.
>>>>
>>>> Note: I am not a YANG doctor; I see that a separate YANG doctor review was
>>>> performed, and I assume that review has covered Section 3.
>>>>
>>>> General comment:
>>>>
>>>> This document is targeted to Standards Track, yet defines a YANG model for
>> an
>>>> Experimental protocol, NPT66; is that acceptable? (I don't know, but I
>> feel
>>>> the question needs to be raised, given also the text of
>>>> draft-ietf-v6ops-ula-usage-considerations-02.)
>>>
>>> [Med] The document defines NPTv6 as a "feature". It does not recommend nor
>> argue against the use of NPTv6 per se.
>>>
>>> FWIW, I'm aware of one Standards Track RFC which lists NPTv6 as one of its
>> deployment scenarios: RFC6887.
>>>
>>> ==
>>> PCP can be used in various deployment scenarios, including:
>>> ..
>>>
>>> o IPv6-to-IPv6 Network Prefix Translation (NPTv6) [RFC6296]
>>> ==
>>
>> Well, I raise the question for consideration by the IESG
>
> [Med] Your initial comment was fair, Tim.
>
> ; while there's a
>> precedent here - and probably elsewhere - it feels odd having a Standards
>> Track document supporting an Experimental one.
>>
>> Could the NPTv6 definitions be extracted to a separate RFC, as you have done
>> with some other elements, or are they shared with Standards Track mechanisms?
>>
>
> [Med] NPTv6 part can be published in a separate document as an augment to
> draft-ietf-opsawg-nat-yang. That is indeed one possibility. Registering an
> entry in the IETF XML Registry assumes "Specification is Required" and adding
> a name in the "YANG Module Names" registry is based on "RFC Required". So
> having an experimental YANG document for NPTv6 would be OK.
>
> Another approach would be to remove the NPTv6 part from the main YANG module,
> but define the nptv6 augment in a dedicated section and make it clear that
> section is not normative. This will be easy to handle.
>
> Any preference?
Either would be an improvement. My preference would be for the first one, given
I recall you also have other complementary documents to the main one (and I
think the YANG doctor originally asked whether there should be a high level NAT
model and then one model per NAT type).
>>>> Nits:
>>>>
>>>> p.4 - I think an Internal Host doesn't really "solicit" a NAT capability;
>>>> that
>>>> implies some messaging between the host and the NAT. Perhaps say "need to
>>>> use",
>>>> or something else.
>>>
>>> [Med] Works for me. Thanks.
>>>
>>>>
>>>> Appendix - it would perhaps be easier for the reader if the same
>>>> documentation
>>>> prefixes were used to refer to internal and external networks throughout
>> the
>>>> examples, though this is only a minor style point.
>>>
>>> [Med] I updated where it makes sense.
>>>
>>>>
>>>> Section A.11 - the ULA prefixes used here are not (or very unlikely to
>> be!)
>>>> true ULAs with randomised prefixes. Again, a style point. Perhaps some
>>>> documentation ULAs need to be defined elsewhere.
>>>
>>> [Med] As explicitly stated in titles ("Example of NPTv6 (RFC6296)" and
>> "Connecting two Peer Networks (RFC6296)"), these examples are extracted from
>> RFC6296. We are re-using the same prefixes as those in 6296-examples.
>>
>> Again, it feels odd though looking at them. The alternative is to use a true
>> ULA prefix (roll the dice!).
>>
>
> [Med] Deal!
>
>> Tim
>
Regards,
Tim
_______________________________________________
OPSAWG mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsawg
