Subject: Re: Gen-art LC review: draft-ietf-6lo-dect-ule-08

From: Jari Arkko <[email-masked]>
Date: Thu, 15 Dec 2016 11:21:04 +0200

Many thanks for the in-depth review, Robert.

Authors — are there any comments or updates to the document based on Robert’s feedback?

Jari

---

From: Jens Toftgaard Petersen <[email-masked]>
Date: Thu, 15 Dec 2016 22:04:45 +0000

Hi Robert,

Many thanks for your review. See my comments and answers inline below.

Best regards,
  Jens

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: 28. november 2016 21:22
To: General Area Review Team <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Gen-art LC review: draft-ietf-6lo-dect-ule-08

I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair.  Please treat these comments just like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-6lo-dect-ule-08
Reviewer: Robert Sparks
Review Date: 28 Nov 2016
IETF LC End Date: 02 Dec 2016
IESG Telechat date: 15 Dec 2016

Summary: Ready with nits

Nits/editorial comments:

First, forgive me, but I need to grumble a little bit:

The way this document approaches standardization makes me very uncomfortable.
The language is passive and relies on inference to the point that it risks being vague. If this review were earlier in the document's life-cycle, I would strongly suggest a complete restructure focusing on explicitly specifying what the implementation is supposed to do.

But, the document has had several reviewers who didn't trip up on this point, and the working group believes it is implementable, so I'm going to set that aside and provide some concrete suggestions for removing some nits from the existing text.

In document order:

1) In section 2.1 "This draft defines 6LoPAN as one of the possible protocols to negotiate". That's not what this draft appears to do. Rather, it defines behavior once this 6LoPAN over DECT ULE has been negotiated. Some other document is defining the negotiation. I suggest replacing the sentence with "[TS102.939-1] defines this negotiation and specifies an Application Protocol Identifier of 0x06 for 6LowPAN. This document defines the behavior of that Application Protocol".

[Jens]: Very good comment and suggested wording. Is implemented in revision -09

2) The "not recommended" in the last sentence of 2.3 looks like it should be a
2119 keyword (NOT RECOMMENDED). Similarly, the "shall" in the last sentence of the first paragraph of 2.4 looks like it should be a SHALL (consider using MUST instead).

[Jens]: I agree. Is implemented in revision -09

3) At the mention of LOWPAN_IPHC in the second paragraph of 2.4, consider referencing RFC6282. It's not clear what the sentence is really trying to convey, though. "all the requirements" is very vague - can you point to a specific requirement list somewhere? "It is expected" implies that you believe there's a chance that it might fail. Could the sentence be removed (you cover this in 3.2) or be replaced with a more direct statement?

[Jens]: Agreed, is covered in section 3.2. Will be removed in revision -09

4) In the first section of 3.1 you have "The PP MUST be pageable".
Interestingly, the word "pageable" does not yet appear anywhere in the RFC series. Please add a reference into the ETSI docs that will lead the reader to a definition.

[Jens]: I don't think we have definition of the term we can refer to. Will change to an explanatory wording in revision -09.

5) In the last paragraph of 3.2 (before 3.2.1), third sentence, you introduce using the multi-link subnet approach. Please either add a reference to
RFC4903
here, or point forward to section 3.3.

[Jens]: A reference to RF4903 added in revision -09

6) In section 3.2.1, third paragraph, you say addresses are derived "similar to the guidance of [RFC4291]. I don't believe that is sufficient. Perhaps you should say "following the guidance in Appendix A of [RFC4291]"?

[Jens]: Yes, your suggestion is more accurate. Will be done revision -09.

7) The last paragraph of 3.3 says "The FPs operation role in such scenario are rather like Backbone Routers (6BBR) than 6LBR, as per [I-D.ietf-6lo-backbone-router]." Is this trying to _specify_ the behavior of the FP in this scenario? If not, it's unclear what the sentence is trying to accomplish. If so, then the sentence should be "The FPs in such a scenario behave as Backbone Routers (6BBR) as defined in [I-D.ietf-6lo-backbone-router]." And that reference should be normative, rather than informative.

[Jens]: I agree the wording is bit vague, but I believe we cannot refer to work in progress [I-D.ietf-6lo-backbone-router] in a normative way. I will tightening the wording revision -09

---

From: Jens Toftgaard Petersen <[email-masked]>
Date: Thu, 15 Dec 2016 22:07:35 +0000

Hi Jari,

All the comments have been addressed and the document is updated to new revision -09.

Best regards,
  Jens

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: 15. december 2016 10:21
To: Robert Sparks <[email-masked]>
Cc: General Area Review Team <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Gen-art LC review: draft-ietf-6lo-dect-ule-08

Authors - are there any comments or updates to the document based on Robert's feedback?

Jari

---

From: Jari Arkko <[email-masked]>
Date: Fri, 16 Dec 2016 00:30:45 +0200

Great - thanks!

Jari

---

From: Robert Sparks <[email-masked]>
Date: Fri, 16 Dec 2016 17:30:55 -0600

Just one comment at the end:

> [Jens]: I agree the wording is bit vague, but I believe we cannot refer to work in progress [I-D.ietf-6lo-backbone-router] in a normative way. I will tightening the wording revision -09
You _can_ refer normatively to a work in progress (and I think it may 
still be the right thing to do here). The consequence is that this 
document would stay in the RFC Editor's queue in a state known as 
MISSREF (for missing reference) until the referenced document was 
approved for publication as an RFC. You can see examples of this at work 
on https://www.rfc-editor.org/current_queue.php.

---

From: Jens Toftgaard Petersen <[email-masked]>
Date: Tue, 20 Dec 2016 12:26:20 +0000

Hi Robert,

Thanks for your clarification of normative references to work in progress. 

I would prefer to keep the reference as in the updated version -09: 

"The FPs in such a scenario should behave as Backbone
   Routers (6BBR) as defined in [I-D.ietf-6lo-backbone-router]."

Are you OK with that?

Best regards,
  Jens

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: 17. december 2016 00:31
To: Jens Toftgaard Petersen <[email-masked]>; General Area Review Team <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Gen-art LC review: draft-ietf-6lo-dect-ule-08

On 12/15/16 4:04 PM, Jens Toftgaard Petersen wrote:
> To: General Area Review Team <[email-masked]>; [email-masked]; 
> [email-masked]; [email-masked]
> 5) In the last paragraph of 3.2 (before 3.2.1), third sentence, you 
> introduce using the multi-link subnet approach. Please either add a 
> reference to
> RFC4903
> [Jens]: I agree the wording is bit vague, but I believe we cannot 
> refer to work in progress [I-D.ietf-6lo-backbone-router] in a 
> normative way. I will tightening the wording revision -09
You _can_ refer normatively to a work in progress (and I think it may still be the right thing to do here). The consequence is that this document would stay in the RFC Editor's queue in a state known as MISSREF (for missing reference) until the referenced document was approved for publication as an RFC. You can see examples of this at work on https://www.rfc-editor.org/current_queue.php.

---

From: Robert Sparks <[email-masked]>
Date: Tue, 20 Dec 2016 08:38:10 -0600

>     Routers (6BBR) as defined in [I-D.ietf-6lo-backbone-router]."
Maybe. I'm not the expert here, so all I can do is ask (what are 
hopefully useful) questions:

Here's one way to help figure this out: Would you be ok deleting the 
sentence and the reference? (I'm not asking you to do that, just to 
consider what it would mean to the resulting set of implementations if 
you did.)

If you think people will build the right software with that sentence 
missing, and you'll get the interoperability you're aiming for, then 
it's fine as an Informative reference. This would be the case if what 
you're really doing with that sentence is saying "other documents in the 
base protocol this is building on require you to behave this way, we're 
just pointing at that here to remind you of that fact".

If that's going to leave implementers guessing at what their 
implementation is supposed to do, and interoperability will suffer, then 
it's normative. (What you're really doing with that sentence is telling 
the implementers something _new_ - that they SHOULD behave as a 6BBR in 
this situation, and nothing else tells them to do that, and the 
reference is here to tell them how to do that).

Alternatively, if it's just fine that some large subset _doesn't_ behave 
as a 6BBR, then its fine the way it is. You might consider saying "One 
good way for an FP can behave in such scenarios is as a Backbone 
Router..." instead, to make it clearer that this is just informational 
guidance rather than something that would affect interoperability in the 
resulting implementation base.

Either way, I'm happy leaving it up to you and your ADs at this point.

---

From: Jens Toftgaard Petersen <[email-masked]>
Date: Wed, 21 Dec 2016 09:26:49 +0000

Hi Robert,

Thanks for your useful comment and guidance.

The multi-cell scenario, that the section is addressing, will probably only be used rare cases - currently it is definitely not the primary use case.
I believe that even without the reference to 6BBR the draft has all the information to ensure interoperability between DECT ULE devices. The sentence is rather to remind implementers of "backbone" infrastructure of the guidance in ietf-6lo-backbone-router.
I am fine with current wording, but for me it is also OK changing the wording if that makes it clearer - any guidance from AD?

Thanks and best regards,
  Jens

-----Original Message-----
From: Robert Sparks [mailto:[email-masked]] 
Sent: 20. december 2016 15:38
To: Jens Toftgaard Petersen <[email-masked]>; General Area Review Team <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: Gen-art LC review: draft-ietf-6lo-dect-ule-08

>     Routers (6BBR) as defined in [I-D.ietf-6lo-backbone-router]."
Maybe. I'm not the expert here, so all I can do is ask (what are hopefully useful) questions:

Here's one way to help figure this out: Would you be ok deleting the sentence and the reference? (I'm not asking you to do that, just to consider what it would mean to the resulting set of implementations if you did.)

If you think people will build the right software with that sentence missing, and you'll get the interoperability you're aiming for, then it's fine as an Informative reference. This would be the case if what you're really doing with that sentence is saying "other documents in the base protocol this is building on require you to behave this way, we're just pointing at that here to remind you of that fact".

If that's going to leave implementers guessing at what their implementation is supposed to do, and interoperability will suffer, then it's normative. (What you're really doing with that sentence is telling the implementers something _new_ - that they SHOULD behave as a 6BBR in this situation, and nothing else tells them to do that, and the reference is here to tell them how to do that).

Alternatively, if it's just fine that some large subset _doesn't_ behave as a 6BBR, then its fine the way it is. You might consider saying "One good way for an FP can behave in such scenarios is as a Backbone Router..." instead, to make it clearer that this is just informational guidance rather than something that would affect interoperability in the resulting implementation base.

> To: Jens Toftgaard Petersen <[email-masked]>; General Area Review Team 
> <[email-masked]>; [email-masked]; [email-masked]; 
> [email-masked]
>> [Jens]: Agreed, is covered in section 3.2. Will be removed in 
>> revision
>> -09
>>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 21 Dec 2016 08:18:07 -0600

Thank you for your patience while discussing this with me. I'm also ok with leaving the current text alone at this point. 

RjS

Sent from my iPhone

> On Dec 21, 2016, at 3:26 AM, Jens Toftgaard Petersen <[email-masked]> wrote:
> 
> Hi Robert,
>

---

From: Samita Chakrabarti <[email-masked]>
Date: Thu, 22 Dec 2016 17:11:07 -0800

Hi Jens and Robert:

Here are a few ideas for Jens to avoid trouble referring a non-RFC document
in the Normative section:

* It seems Backbone Router is not a requirement of  dect-ule specification
to work. 6BBR has been mentioned to show how it might work with such
 advanced scenarios.

a) Add an Appendix section and show backbone router related examples and
references there.

[Jens, please refer to RFC7428 for an example on the Appendix section.]

b) Another option is to move entire section 3.3 and 2.5 to the Appendix
section [ Not sure if that is a good idea at this point ]

c)  Leave it as it is [ i,e backbone router reference goes into informative
reference]

I'd resort to Suresh's suggestion, it is our AD's call at this time.

Thanks,
-Samita

On Wed, Dec 21, 2016 at 1:26 AM, Jens Toftgaard Petersen <[email-masked]> wrote:

> The multi-cell scenario, that the section is addressing, will probably
> only be used rare cases - currently it is definitely not the primary use
> case.
> I believe that even without the reference to 6BBR the draft has all the
> information to ensure interoperability between DECT ULE devices. The
> sentence is rather to remind implementers of "backbone" infrastructure of
> the guidance in ietf-6lo-backbone-router.
> I am fine with current wording, but for me it is also OK changing the
> wording if that makes it clearer - any guidance from AD?
>
> Thanks and best regards,
>   Jens
>
>
> To: Jens Toftgaard Petersen <[email-masked]>; General Area Review Team <
> [email-masked]>; [email-masked]; [email-masked];
> consider what it would mean to the resulting set of implementations if you
> did.)
>
> missing, and you'll get the interoperability you're aiming for, then it's
> fine as an Informative reference. This would be the case if what you're
> really doing with that sentence is saying "other documents in the base
> protocol this is building on require you to behave this way, we're just
> pointing at that here to remind you of that fact".
>
> it's normative. (What you're really doing with that sentence is telling the
> implementers something _new_ - that they SHOULD behave as a 6BBR in this
> situation, and nothing else tells them to do that, and the reference is
> here to tell them how to do that).
>
> as a 6BBR, then its fine the way it is. You might consider saying "One good
> way for an FP can behave in such scenarios is as a Backbone Router..."
> instead, to make it clearer that this is just informational guidance rather
> than something that would affect interoperability in the resulting
> implementation base.
>
> >> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed by the
> IESG for the IETF Chair.  Please treat these comments just like any other
> last call comments.
> >>
> >> The language is passive and relies on inference to the point that it
> risks being vague. If this review were earlier in the document's
> life-cycle, I would strongly suggest a complete restructure focusing on
> explicitly specifying what the implementation is supposed to do.
> >>
> >> But, the document has had several reviewers who didn't trip up on this
> point, and the working group believes it is implementable, so I'm going to
> set that aside and provide some concrete suggestions for removing some nits
> from the existing text.
> >>
> >> In document order:
> >>
> >> 1) In section 2.1 "This draft defines 6LoPAN as one of the possible
> protocols to negotiate". That's not what this draft appears to do. Rather,
> it defines behavior once this 6LoPAN over DECT ULE has been negotiated.
> Some other document is defining the negotiation. I suggest replacing the
> sentence with "[TS102.939-1] defines this negotiation and specifies an
> Application Protocol Identifier of 0x06 for 6LowPAN. This document defines
> the behavior of that Application Protocol".
> >>
> >> 2119 keyword (NOT RECOMMENDED). Similarly, the "shall" in the last
> sentence of the first paragraph of 2.4 looks like it should be a SHALL
> (consider using MUST instead).
> >>
> >> 3) At the mention of LOWPAN_IPHC in the second paragraph of 2.4,
> consider referencing RFC6282. It's not clear what the sentence is really
> trying to convey, though. "all the requirements" is very vague - can you
> point to a specific requirement list somewhere? "It is expected" implies
> that you believe there's a chance that it might fail. Could the sentence be
> removed (you cover this in 3.2) or be replaced with a more direct statement?
> >>
> >> Interestingly, the word "pageable" does not yet appear anywhere in the
> RFC series. Please add a reference into the ETSI docs that will lead the
> reader to a definition.
> >>
> >> [Jens]: I don't think we have definition of the term we can refer to.
> Will change to an explanatory wording in revision -09.
> >>
> >> 6) In section 3.2.1, third paragraph, you say addresses are derived
> "similar to the guidance of [RFC4291]. I don't believe that is sufficient.
> Perhaps you should say "following the guidance in Appendix A of [RFC4291]"?
> >>
> >> 7) The last paragraph of 3.3 says "The FPs operation role in such
> scenario are rather like Backbone Routers (6BBR) than 6LBR, as per
> [I-D.ietf-6lo-backbone-router]." Is this trying to _specify_ the behavior
> of the FP in this scenario? If not, it's unclear what the sentence is
> trying to accomplish. If so, then the sentence should be "The FPs in such a
> scenario behave as Backbone Routers (6BBR) as defined in
> [I-D.ietf-6lo-backbone-router]." And that reference should be normative,
> rather than informative.
> >>
> still be the right thing to do here). The consequence is that this document
> would stay in the RFC Editor's queue in a state known as MISSREF (for
> missing reference) until the referenced document was approved for
> publication as an RFC. You can see examples of this at work on
> https://www.rfc-editor.org/current_queue.php.
> >
>
>